the previosuly introduced searchBySystemTag was not overwritten in
NonExistingFolder and could run the inherited method.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
ci: pro forma check of existence of internal method
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>
feat: specify media type via url path: systemtags-current/$mediaType
- 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>
PoC: SystemTags endpoint to return tags used by a user with meta data
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>
Fix file_get_content signatures to make it clear it can return false
In File::getContent, which must return a string, throw an Exception
instead of returning false.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
only fetch the data for mounts inside a folder when needed
for most operations we don't actually care about any mounts inside a folder, only for metadata that needs to propagate across storage boundaries (size, etag, mtime) do we need all the submount info.
By only loading this data when needed we can save a bunch of storage setup in a number of cases
Signed-off-by: Robin Appelman <robin@icewind.nl>
As the user folder might be initialized by the root from two levels
down the hierarchy, passing this as a parent only works if the path matches
Signed-off-by: Julius Härtl <jus@bitgrid.net>