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>
The settings where combined last minute but at the same time the activities
where not adjusted to map an existing setting so the filter was not possible
to even limit it to the types that the activities had.
Signed-off-by: Joas Schilling <coding@schilljs.com>
- 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>
Addressbooks and Calendar data are destroyed through hook OC_User::pre_deleteUser, which when it reaches the backends sends AddressBookDeletedEvent/CalendarDeletedEvent typed events, which in turns generates activities that aren't deleted until they expire.
This can probably lead to old activities being visible for a new user created with the same uid.
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)
