If 'verify_bucket_exists' is set to false in the config.php s3 configuration, it's supposed to avoid
verifying that the bucket exists. However empty(falsy) will always return true, so this condition
would not work.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
OC\Files\Cache\Cache::get can return string|false|null, not just string|false.
- nextcloud/server#26270 added handling of false, but null is needed too.
- Well, or we change the default $resullt to false, but I'm not sure if that has other ramifications and the real need here is to simply catch situations where the cache source storage path is not valid for whatever reason
Related: nextcloud/server#19009
Signed-off-by: Josh Richards <josh.t.richards@gmail.com>
the previosuly introduced searchBySystemTag was not overwritten in
NonExistingFolder and could run the inherited method.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- in this backport we have to drop the breaking addition in
\OCP\Files\Folder
- this requires adjustments in check for the existance of the method but
also in testing
- another change in \OCP\SystemTag\ISystemTagManager can be applied as
this interface is not implemented elsewhere
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
createNode() is protected and used by Folder, but being an internal-only
method it shall not be exposed in the Folder or IRootFolder interface.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- fixes a regression when deleting folders while music app was enabled,
for a LazyRoot was passed to this method.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
currently `[$userId, $rootId]` is used as the unique key for storing mounts in the mount cache,
however there are cases where the same rootid is mounted in multiple places for a user which currently leads to not all of those mounts being added to the cache.
Previously this didn't matter as the mount cache was only used to list users with access to a specific file, so a user having access to the file multiple times didn' change anything.
With 24 the mount cache is used for more cases and multiple mounts for the same id becomes relevant.
While I think there isn't a real negative effect atm besides missing the optimized path we should ensure that the mounts are properly listed
Signed-off-by: Robin Appelman <robin@icewind.nl>
- 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>
