- Issue: With a large volume of attachments, the "Attach File" button is pushed to the bottom
- "Attach File" stays at the top of the pile
- Small explore files button added so that users can use the File View to navigate/filter through files
- Expanded Explore Files button when attach file action is hidden
- Added `file_type` to Files, this is useful for filtering and visibility
- Added "Type" to File List View
- Patch to set File Type in all files
* build(deps): update redis client to v4 in legacy mode
* fix: node17+ - prefer ipv4
* chore: use redis client v4 api (async) and adapt error handling
* fix: timeout by exiting if not in watch mode
* fix: parse message before republishing
---------
Co-authored-by: Ankush Menat <ankush@frappe.io>
* fix: procure db config from single authority
ensures that configuration is uniformely procured from local.conf
instead of making use of hard to audit multilevel fallback logic
Implementation Note:
- `get_db(host, port, user, password)` was stripped of any optional
argument and therefrom all errors where fixed.
- All occurances of `grep 'frappe.db.db_'` where changed to
`frappe.conf.db_`
* fix: revert unnecessary breaking changes
We eagerly fetch shared documents for ANY `get_list` query, even when
user has full read acess doctype, where it's moot to consider adding
shared document as separately.
This eliminates one entire db call from get_list and in most cases
get_list will translate to single DB call, hence probably worth the
additional complexity.
20 results are rarely scrolled by user.
Most users end up typing more characters to narrow down results. This
way on large table we end up reading significantly fewer rows.
The way relational DBs work is they keep filtering and reading rows one
by one until limit is hit, so smaller the limit the better.
Also defer document refreshes by up to 5 seconds.
Rarely anyone needs truly realtime list view updates. It's better batch
them over at least 5 or so seconds if there's a high volume of changes.
Attempt to normalize query by removing "variables"
This gives a different view of similar duplicate queries.
These two are distinct queries:
```sql
select * from user where name = 'x'
select * from user where name = 'z'
```
But their "normalized" form would be same:
```sql
select * from user where name = ?
```
This helps highlight queries ran in loop which might not register as
duplicate but are possibly "duplicate".
