Make it possible to filter by tags with REPORT method

[PVince81]

Description

Enhanced the REPORT method on the Webdav endpoint and added a
"oc:favorite" filter rule. When set, it will return a flat list of
results filtered with only favorite files.

The web UI was also adjusted to use this REPORT method instead of the
private API endpoint.

Related Issue

Fixes #23263

Motivation and Context

This makes it possible for other clients like desktop and mobile to retrieve a flat filtered list of favorite files. The previous API was private and was not supposed to be used, but the REPORT method and the webdav endpoint are public. @davivel @nasli @dragotin @guruz

How Has This Been Tested?

1. Favorite a few files in folders and subfolders, share one of them with link (for the share indicator).
2. Go to the "Favorites" section in the web UI.
3. Check the network console and see that it's using REPORT to get the results.
4. Check that the displayed results look fine and also contain the share indicator from the previous link share (it's part of the Webdav response)

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

Please review @DeepDiver1975 @butonic @VicDeo @guruz @davivel @SergioBertolinSG @nasli

[mention-bot]

@PVince81, thanks for your PR! By analyzing the annotation information on this pull request, we identified @LukasReschke, @nickvergessen and @DeepDiver1975 to be potential reviewers

[PVince81]

I just saw that we can actually have different report types using the report name.

The report here was called "filter-files". The question maybe is whether we want to separate all these into separate reports:

• filter-systemtags
• filter-favorites
• get-files (for pagination)
• search-files ?

[PVince81]

The advantage of a single "filter-files" report is that you can combine filters and intersect results, but it also increases complexity because of this.

[VicDeo]

@PVince81
is it ok, that a response has several dummy parts like that in addition to the file list itself?

  <d:propstat>
   <d:prop>
    <oc:size/>
   </d:prop>
   <d:status>HTTP/1.1 404 Not Found</d:status>
  </d:propstat>
 </d:response>

If yes, consider my comment for 👍

[PVince81]

@VicDeo yes, this happens when requesting a property that doesn't exist on all nodes.
The "oc:size" property only exists on folders, not files. So the file entries will tell so in the 404 block.
This is a standard PROPFIND response.

[PVince81]

@DeepDiver1975 @butonic do we agree on the API-side of this ? Basically use multiple filters within the same report "filter-files".

[butonic]

basically the report tesult is a list of files. What we want to change are the filter criteria, eg. by favorite, tag, mtime range, file name, file content ...

so yes, keep a single filter-files report.

[PVince81]

Thanks, merging.

Pagination as it was mentionned is a topic for another time, see #13915.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.