| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
|
|
|
|
| |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|\
| |
| |
| |
| | |
nextcloud/feat/add-delta-sync-to-subscription-calendars
feat(webcal): only update modified and deleted events from webcal calendars
|
| |
| |
| |
| | |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|/
|
|
|
|
| |
This is mandated by the RFCs.
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
|
|
|
|
| |
Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
|
|
|
|
|
|
| |
`IExpressionBuilder::and()` without parameters
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
|
|
|
|
| |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
|
|
|
|
| |
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
|
|
|
|
|
|
|
| |
Not sure about the SimpleContainer modification, let’s see what CI says
about that.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Patrick Fischer <mail@patrickfischer.ch>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
|
|
| |
calendars)
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Benjamin Gaussorgues <benjamin.gaussorgues@nextcloud.com>
|
|
|
|
|
|
|
| |
fetchAll inflates memory. Fetching in a loop allows GC to run earlier
and more often.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
|
|\
| |
| | |
Calendar optimizations
|
| |
| |
| |
| | |
Signed-off-by: Robin Appelman <robin@icewind.nl>
|
| |
| |
| |
| | |
Signed-off-by: Robin Appelman <robin@icewind.nl>
|
| |
| |
| |
| | |
Signed-off-by: Jamie McClelland <jm@mayfirst.org>
|
|/
|
|
|
|
| |
see https://github.com/nextcloud/calendar/issues/4758
Signed-off-by: Jamie McClelland <jm@mayfirst.org>
|
|\
| |
| | |
fix(dav): close cursor when fetching max id
|
| |
| |
| |
| | |
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
|
|/
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
|
|
|
|
|
|
| |
Closes #20804
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
|
|
|
|
|
|
|
|
| |
incrementing synctoken
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
multiple DB calls in transactions
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>
|
|\
| |
| | |
fix(dav) Handle Calendar trashbin UID conflicts by removing the deleted calendar object
|
| |
| |
| |
| | |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|
|/
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
|
|
| |
Also fixed numericToString to correctly convert float to int if it fits
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Anna Larch <anna@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>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Anna Larch <anna@nextcloud.com>
|