- 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>
In some scenarios (file not in cache, but partial data of it in the
object), Cache->get() might return an array, which leads to errors like
"Call to a member function getId() on array".
So check whether the returned entry is of type ICacheEntry before doing
operations on it in Cache->remove().
Fixes: #33023
Signed-off-by: Jonas <jonas@freesources.org>
Directory entry file names are now normalized in getMetaData(),
getDirectoryContents() and opendir().
This makes the scanner work properly as it assumes pre-normalized names.
In case the names were not normalized, the scanner will now skip the
entries and display a warning when applicable.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
The encoding check for file names is now happening the Scanner, and an
event will be emitted only if the storage doesn't contain the encoding
compatibility wrapper.
The event is listened to by the occ scan command to be able to display a
warning in case of file name mismatches when they have NFD encoding.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
The scanner would not find a NFD-encoded file name in an
existing file list that is normalized.
This normalizes the file name before scanning.
Fixes issues where scanning repeatedly would make NFD files flicker in
and out of existence in the file cache.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
