Before: Find all entries in `dav_shares` with `access = 5` for the user's principal, as well as group and circle memberships.
After: Find all entries in `dav_shares` with `access = 5` solely for the user's principal.
Future support for unsharing group or circle principals could be considered as a feature enhancement.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
It is not possible to share address books with circles so it is
pointless to query for address books shared with joined circles.
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
* Accept non repeatable read and INSERT conflict by another read
* Handle replication edge case
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Sabre executes the proppatch callback *after* calling updateAddressbook
and not synchronously. That means the code inside the callback was run
outside a database transaction. This moves the atomic helper into the
callback to create the expected transaction span.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Early return can operate on the input array
* SQL can check be used to check for address book ID inclusion
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
pruneOutdatedSyncTokens accidentally deletes all entries of the calendarchanges table
instead of leaving $limit elements in the table
Signed-off-by: Christof Arnosti <charno@charno.ch>
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>
Now that we're in a transaction, we can reuse the sync token's previous value without trouble, and rewrite the increment UPDATE query without dirty direct SQL.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
In a lot of methods we're doing read-after-writes (for instance calling
updateProperties after touching calendar objects).
There's also a lot of deleting methods that do stuff sequentially which
could cause trouble.
This should avoid this kind of issues.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
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>
