This allows to just UPDATE the card row instead of deleting it and reinsert it. It's very similar to https://github.com/nextcloud/server/pull/30120 for calendars.
As we need the addressbookid exposed, this introduces OCA\DAV\CardDAV\Card that extends Sabre's.
I chose specifically NOT to auto-inject LoggerInterface in Addressbook like in #30120 because the chain of DI is huge just for ONE simple call and it would break an existing dirty call (OCA\Contacts calling OCA\DAV) of ContactsManager in Contacts: https://github.com/nextcloud/contacts/pull/1722 (in SocialApiService), but this is debatable.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
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 adds CalDAV support for app generated calendars,
which are registered to the nextcloud core.
This is done by adding a dav plugin which wraps
all ICalendarProviders into a Sabre plugin (inspired by the deck app).
Add unit test for AppCalendar wrapper plugin and calendar object implementation.
Signed-off-by: Ferdinand Thiessen <rpm@fthiessen.de>
We remove all outdated sync tokens, based on their auto-incremented ID.
By default we only keep the last 10 000, but this can be configurable.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
findBinaryFinder is now a service that is still private but with some
minor optimization (remove the hasKey check).
isFunctionEnabled is now in OCP\Util
Both function are still keep but all internal usage in nextcloud/server
were migrated to the new usage, so that we can remove it in 26
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
- Use IEventDispatcher instead of deprecated symfony dispatcher
- Use LoggerInterface where possible
- Use php 7.4 properties
- Add type hinting where possible
- Move federation hooks to a seperate listener
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
- Introduce a new CalendarObjectMovedEvent typed event dedicated for
this operation
- Handle the event in the activity backend and add new appropriate activity subjects
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The current implementation only saves them as string. It seems they can
be more complex than that, and that objects were saved directly.
You may find such objects saved in some production databases by
executing:
```sql
SELECT * from oc_properties where propertyvalue = 'Object';
```
This commit adds a repair job to clean all of these "broken" properties
values, adds a new database column to save the type of the property, and
handles converting from and to correct values.
Implementation is very similar to SabreDAV's own PDO backend: 4921806dfb/sabre/dav/lib/DAV/PropertyStorage/Backend/PDO.php
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
Built-in profiler
This adds the required API for collecting information about requests. This information
can then be displayed with the new 'profiler' app.
Joas Schilling
Thomas Citharel
Arthur Schiwon
Anna Larch
Robin Appelman
Ferdinand Thiessen
Julius Härtl
Claus-Justus Heine
Christoph Wurst
Julien Veyssier
Carl Schwan
Vincent Petry
John Molakvoæ
Christopher Ng
Côme Chilliet
Louis Chemineau