The FilesSearchProvider performs a search in the user folder, which in turn performs the search in the caches. QuerySearchHelper first does a generic search in the filecache table in the database and, then, formats the results using the specific storage that contains each result, which may also filter them out. For example, in the case of the ACLCacheWrapper in the groupfolders app, if the current user does not have read permissions for that file no formatted entry is returned.
Due to that, it could happen that a search including only those files accessible by a user would have returned certain files, but currently those files are missing in the unified search results because their place is taken by other files that were later filtered out. Moreover, as the results are less than the limit specified when doing the search the UI assumes that there are no more results available, and it does not show the Load more results button.
Although the problem is easily reproducible with group folders the search logic itself is in server and (I guess) it could potentially happen with other storages unrelated to group folders.
Possible solution
This could be solved by looping the current generic search and result filtering in QuerySearchHelper until the amount of requested results is reached (or there are no more results). Nevertheless, this approach could potentially cause long loops in the search requests, for example if the user does not have read permissions in a large subfolder of a group folder with many matching files... 🤔
In any case, the search results include a cursor with the position that the paginated search should continue from, so when loading more results the UI could simply continue from that cursor. Note, however, that right now the UI does not use the cursor, and whenever more results are requested it just increases the limit starting again from the beginning (which could be also seen as a separate bug).
How to test
Alternatively to the reproduction steps below there is an E2E test in the groupfolders app (with slightly different steps).
- As an admin, open the Accounts settings
- Create a group
- Create user manager and add it to the group
- Create user restricted and add it to the group
- Enable Team folders
- Create a team folder for the group
- Enable advanced permissions and set user manager as the user that can manage them
- Log in as user manager
- Open the Files app and enter in the team folder
- Create folders subfolder1 and subfolder2
- In subfolder1, create folders test1 to test6
- If done with a script either an incremental mtime needs to be provided, or a sleep of at least 1 second needs to be used between each creation to have consistent sorting of the results
- In subfolder2, create folders test7 to test12
- Same consideration as before with the mtime
- Deny read permissions to subfolder2 to user restricted
- Log in as user restricted
- Search for test
Expected result
Folders test1 to test5 are found, and Load more results is shown
Actual result
No folders are found, and Load more results is not shown either
The
FilesSearchProviderperforms a search in the user folder, which in turn performs the search in the caches.QuerySearchHelperfirst does a generic search in the filecache table in the database and, then, formats the results using the specific storage that contains each result, which may also filter them out. For example, in the case of theACLCacheWrapperin the groupfolders app, if the current user does not have read permissions for that file no formatted entry is returned.Due to that, it could happen that a search including only those files accessible by a user would have returned certain files, but currently those files are missing in the unified search results because their place is taken by other files that were later filtered out. Moreover, as the results are less than the limit specified when doing the search the UI assumes that there are no more results available, and it does not show the Load more results button.
Although the problem is easily reproducible with group folders the search logic itself is in server and (I guess) it could potentially happen with other storages unrelated to group folders.
Possible solution
This could be solved by looping the current generic search and result filtering in
QuerySearchHelperuntil the amount of requested results is reached (or there are no more results). Nevertheless, this approach could potentially cause long loops in the search requests, for example if the user does not have read permissions in a large subfolder of a group folder with many matching files... 🤔In any case, the search results include a cursor with the position that the paginated search should continue from, so when loading more results the UI could simply continue from that cursor. Note, however, that right now the UI does not use the cursor, and whenever more results are requested it just increases the limit starting again from the beginning (which could be also seen as a separate bug).
How to test
Alternatively to the reproduction steps below there is an E2E test in the groupfolders app (with slightly different steps).
Expected result
Folders test1 to test5 are found, and Load more results is shown
Actual result
No folders are found, and Load more results is not shown either