Search does not find all files

[tbsbdr]

Steps to reproduce

1. login at https://ocis.ocis-web.latest.owncloud.works/
2. Set pagination to Items per Page: "All"
3. Upload 2.000 Files names File1, File2 ... File2000 (download test data from here: https://cloud.owncloud.com/index.php/s/xnvEvwmwbC7qF7a)
4. search for "file" in "all files"
5. SERP shows 200 items

Folder with 2000 files inside:

Result page with only 200 files found:

Expected behaviour

• All 2000 files should be found

Actual behaviour

• only 200 of 2000 files are found

[kulmann]

@micbar @aduffeck do we have pagination on the REPORT request? 🤔

[micbar]

@micbar @aduffeck do we have pagination on the REPORT request? 🤔

We do not have pagination on WebDAV requests at all.

[AlexAndBear]

Actually, we don't have pagination.
There is also an infinity flag we can set to retrieve an unlimited amount of results, but we could set a magic number like 1 mio or so.

How to proceed @kulmann @tbsbdr @micbar

(Currently we have a limit of 30, instead of 200)

[tbsbdr]

Proposal as long as we don't have pagination from the server:

• Default Limit We set a cost-effective default (=fast enough, but still useful amount of result) of max results, ex. 300 items
• Communication If more than 300 items where found, we communicate "Found many, showing the 300 best matching results."

Any additions or objections @aduffeck @micbar @janackermann ?

[AlexAndBear]

@tbsbdr do we really show the best matching results?

Would rather go with: "Found 400 matches, showing the first 300 results. (maybe)"

[tbsbdr]

do we really show the best matching results

@micbar can we say "best matching results" or are the results non-weighted?

[aduffeck]

@tbsbdr @micbar Search results are sorted by relevance, meaning results with the highest score will be returned first.

[AlexAndBear]

Pretty cool! So we need a decision if we want to proceed with this proposal.

Requirements:

• Dav Report needs to emit a meta field with the total found items
• Frontend implementation

[micbar]

@janackermann @tbsbdr the proposal is fine IMO

[aduffeck]

@janackermann @tbsbdr you can already specify the number of results being returned using the <oc:limit> tag if you don't like the 200 results default. Other than that I will prepare a PR that will add the total number of results to the response.

[AlexAndBear]

@tbsbdr

1. Do we want to show "Found many, showing the 300 best matching results." or "Found [numer of results], showing the 300 best matching results."
2. What about the standard list info, do we want to omit it?
   
3. What about the footer text if the result count doesn't exceed the limit of 300 ?

[tbsbdr]

• @aduffeck 200 is fine for a start, we'll change the total number of results upon feedback while beta.

Do we want to show "Found many, showing the 300 best matching results." or "Found [numer of results], showing the 300 best matching results."

• 👍 lets add the [number of results]

What about the standard list info, do we want to omit it?

• I'd recommend to omit the standard list info, if the limit is exceeded, to avoid confusion if the standard list info refers only to the shown files (=subset) or the whole number of results. I also assume the user value of showing the list info for the subset is limited as the items of the subset is chosen by the search algorithm and is more "fluid". but no hard feelings on this point.

What about the footer text if the result count doesn't exceed the limit of 300 ?

• stays as is like xx items with xx MB in total (xx files, xx folders)

[AlexAndBear]

@tbsbdr
Works like designed #7267

But we have a problem with oc10 as backend, there is no field that gives us the number of the matching results, so 200 is the hard limit, and we cannot communicate to the user if there might be more results

[tbsbdr]

hm.. this might have a dependency on how we solve the slow loading state of the filelist (#7038)

some thoughts:

• pagination I'm not a fan of the pagination in the regular files list , but for the search results a pagination is legit
• lazyloading would be legit for both, regular files list and search result page, main problem here is to make it accessible
• complexity maintenance pagination comes with some complexity for features like sorting, grouping, select all / batch etc. -> if we decide to have pagination only for search results, it doesn't feel right to maintain such complexity for a one-time pattern thats not reused in other views

Proposals:

1. Short term favorite: a (cheap?) quickfix could be to communicate in oc10 somthing like "showing max. of 200 results"
2. return the total number of results so that we can provide a pagination
3. Long term favorite: show results via lazy loading (has a11y issues afaik)

--> I would favor Proposal nr 1, would you agree @janackermann ?

[AlexAndBear]

Implemented: Short term favorite: a (cheap?) quickfix could be to communicate in oc10 somthing like "showing max. of 200 results"