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>
* Remove double hook: the OC_User::changeUser triggers an
OC\AccountManager::userUpdated and the app is already listening to this
signal in its Application definition
* Make createCard not check if an card exists if we already checked
previously. We also don't try to get the card if the user is disabled
as we don't use the card in this case
We this change we go from 100 DB requests to 80 DB requests when saving
an user email address.
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
(cherry picked from commit c6fd482edf33214a9ad4787e4cac278f871fa7c8)
