Reject calendars that
- are subscriptions
- are not writable
- are shared with a user
- are deleted
- don't support VEVENTs
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
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>
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>
Old comparison implementation compares each element of the array against each other with no respect for the associated array label, which leads to wrongful removals because one value is accidentally present in a completely different label. New comparison works 'by-label' individually.
Partly fixes#41084 because changes between 'SEQUENCE' not present, 'SEQUENCE:0' and 'SEQUENCE:1' were not detected in the old implementation and thus no email update sent.
Co-authored-by: Christoph Wurst <ChristophWurst@users.noreply.github.com>
Signed-off-by: Robert C. Schaller <gtbc_robert.schaller@rsxc.de>
