Big federated setups may need a longer timeout, which they now can
configure.
Signed-off-by: Pablo Zmdl <pablo@nextcloud.com>
Co-authored-by: Josh <josh.t.richards@gmail.com>
Client.preventLocalAddress expects an absolute URL, which means the base_uri option cannot be used.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
The request method is available since 29 and thus we can finally use the modern http client to send the report request for the addressbook sync.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
Synced from LDAP to profile:
- Date of birth
Synced from LDAP to SAB (via the profile):
- Biography
- Date of birth
Original code by Jake Nabasny (GitHub: @slapcat)
Co-authored-by: Jake Nabasny <jake@nabasny.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
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>
Fix generation of birthday calendar events for the 29th of February.
A recurring event for the 29th of February in the (default) Gregorian
calendar system would only generate instances in leap years. Fix this
behaviour by generating recurring events for the last day of February,
the 29th on leap years and the 28th otherwise.
Signed-off-by: Mattia Narducci <mattianarducci1@gmail.com>
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>
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>