- search constraints are now fully in control of
SystemTagsInFilesDetector::detectAssignedSystemTagsIn(), avoids
duplication of a WHERE statement
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- only the media part of the mime type can be search, but not the full
mime type. It can be added, should it become necessary.
- thus fixes previously hardcoded selector for image/ types
- also fixes a return type hint
- adds a return type hint
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Target case is photos app: when visiting the tags category, all systemtags
of the whole cloud are retrieved. In subequent steps the next tag is
requested until the browser view is filled with tag tiles (i.e. previews
are requested just as well).
With this approach, we incorpoate the dav search and look for user related
tags that are used by them, and already returns the statistics (number of
files tagged with the respective tag) as well as a file id for the purpose
to load the preview. This defaults to the file with the highest id.
Call:
curl -s -u 'user:password' \
'https://my.nc.srv/remote.php/dav/systemtags-current' \
-X PROPFIND -H 'Accept: text/plain' \
-H 'Accept-Language: en-US,en;q=0.5' -H 'Depth: 1' \
-H 'Content-Type: text/plain;charset=UTF-8' \
--data @/home/doe/request-systemtag-props.xml
With request-systemtag-props.xml:
<?xml version="1.0" encoding="UTF-8"?>
<d:propfind xmlns:d="DAV:">
<d:prop xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns">
<oc:id/>
<oc:display-name/>
<oc:user-visible/>
<oc:user-assignable/>
<oc:can-assign/>
<nc:files-assigned/>
<nc:reference-fileid/>
</d:prop>
</d:propfind>
Example output:
…
<d:response>
<d:href>/master/remote.php/dav/systemtags/84</d:href>
<d:propstat>
<d:prop>
<oc:id>84</oc:id>
<oc:display-name>Computer</oc:display-name>
<oc:user-visible>true</oc:user-visible>
<oc:user-assignable>true</oc:user-assignable>
<oc:can-assign>true</oc:can-assign>
<nc:files-assigned>42</nc:files-assigned>
<nc:reference-fileid>924022</nc:reference-fileid>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
<d:response>
<d:href>/remote.php/dav/systemtags/97</d:href>
<d:propstat>
<d:prop>
<oc:id>97</oc:id>
<oc:display-name>Bear</oc:display-name>
<oc:user-visible>true</oc:user-visible>
<oc:user-assignable>true</oc:user-assignable>
<oc:can-assign>true</oc:can-assign>
<nc:files-assigned>1</nc:files-assigned>
<nc:reference-fileid>923422</nc:reference-fileid>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
…
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
This is done by adding a
```xml
<d:eq>
<d:prop>
<oc:owner-id/>
</d:prop>
<d:literal>$userId</d:literal>
</d:eq>
```
clause to the search query.
Searching by `owner-id` can only be done with the current user id
and the comparison can not be inside a `<d:not>` or `<d:or>` statement
Signed-off-by: Robin Appelman <robin@icewind.nl>
Fixes#15048
Catches the case where a full mimetype is sumbitted in the where like
clause. Before we didn't catch this and it was just forwarded as is
causing invalid queries.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
