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>
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 do not support events after 2038 on 32bits but still behave better
when date range start/end is after 2038.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.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>
- Introduce a new CalendarObjectMovedEvent typed event dedicated for
this operation
- Handle the event in the activity backend and add new appropriate activity subjects
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The timestamp is an int, but we treated it as string. With this patch
the property map is enriched with types and settype casts the value if
necessary.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
When we search for CalDAV objects in the DB we take the first and last
occurence into account. For recurring events that is when they take
place the very first time and the very last time. Searching in a more
specific time range will still match this condition, because the
recurring event starts before the end of the requested range but ends
after the start of the requested range.
Sabre has filters for this. If we apply them on all seach objects of a
search with a time range, then only the recurring events actually taking
place at the time of the requested time range will be returned.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
For API users it looked like any properties could be searched. But it
turned out to be a hand picked list of properties that we index and then
use for the search. To prevent application errors where special props
are not found, I suggest we document and type the allowed values.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The trashbin is one report across all calendars of a user. In order to
refresh the data of a single calendar when one of its events is
restored, we need to know what calendar the event belongs to. There
doesn't seem to be a standard property for a URI, so this adds a custom
Nextcloud prop for the calendar-uri.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
