Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Co-authored-by: Daniel <mail@danielkesselberg.de>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
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>
Address book and calendar sync tokens have a created_at column in 26+
and we need to assign a current timestamp to the existing data at
upgrade so the data isn't cleaned up immediately. Updating the full
table is expensive and fails on clustered setups that limit transaction
size. We don't need a timestamp for the oldest rows so we can skip
updating them.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
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>
Sorting the events by the start date leads to more predictable results for the search API consumers.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
Event recurrences are evaluated at runtime because the database only knows the first and last occurrence.
Given, a user created 8 events with a yearly reoccurrence and two for events tomorrow.
The upcoming event widget asks the CalDAV backend for 7 events within the next 14 days.
If limit 7 is applied to the SQL query, we find the 7 events with a yearly reoccurrence and discard the events after evaluating the reoccurrence rules because they are not due within the next 14 days and end up with an empty result even if there are two events to show.
The workaround for search requests with a limit and time range is asking for more row than requested and retrying if we have not reached the limit.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
