In Agendula's own storage, ticking off the current occurrence of a repeating task now moves the series on to its next date and keeps a completed copy, as tasks.org and Apple Reminders do.
Before, the series stayed open and the completion was a `RECURRENCE-ID` override with `STATUS:COMPLETED` in the same resource. That's valid iCalendar, but Infomaniak's web view and Apple Reminders ignore it and keep showing the task as open, which is what #137 reports. The reporter hasn't confirmed their storage mode yet. With tasks.org/OpenTasks the provider already moves the series on, so this change is about the built-in CalDAV sync.
How it works (`RoomTasksDataSource`):
- Ticking or cancelling the series' **first open occurrence** moves the master to its next open occurrence. Closed overrides on either side become standalone completed copies (new UID, fresh alarm identities), including the ones 1.3.0 left behind. `COUNT` drops by the occurrences used up (counted before `EXDATE`, shared with `splitSeries`), `EXDATE` values before the new start are dropped, and status and progress are reset. An edited occurrence is converted in place, so its id, edits and own properties survive. Lines inside nested components, such as a `VALARM`'s `UID`, are kept.
- Series with `RDATE`s keep the override model, because moving the anchor onto an `RDATE` would re-align the `RRULE`. So do recurring subtasks, whose copies would otherwise pile up under the parent.
- How the series moved is recorded in two new local tables, `advanced_occurrences` and `advanced_detached` (schema v5, migration and migration test included). They are never part of the synced `VTODO`. A record keeps mapping the occurrence to its copy (pruned after 30 days), so the detail screen and reminders find the copy even after it was edited. Every save path goes through one check: when the only thing that changes on a copy is that it reopens (compared as the editor writes values back), the move is undone. That covers undo, the completed section, the editor, the detail screen and other apps through Agendula's provider. The anchor goes back, `COUNT` regains what it spent, the dropped `EXDATE`s return in the list's own value shape, other edits made since are kept, and a reopened state such as 40% stays on the occurrence. Detached overrides come back as overrides; one deleted since, or given its own parent or subtasks, is excluded instead. A copy that was edited, moved or given subtasks, or whose series moved on, changed its rule or was deleted, reopens as a task of its own.
- If a sync discards the local version of a moved series because the server's is newer, the copies of moves the server never saw are deleted too, and the server's own overrides stand for those occurrences. Moves already uploaded are marked settled and left alone.
- `task(series, anchor)` resolves a moved-past occurrence to its copy, so the detail screen and reminder checks see it as done. The repository then acts on the row it resolved, including the detail screen's subtasks, so deleting or saving from a screen opened before the move can't hit the whole series.
- A stale tick (an old notification or widget row) for an occurrence the series has already moved past does nothing.
- Ticking the last open occurrence closes the series, and reopening any of its occurrences reopens the series.
- Any other occurrence (with earlier ones still open) keeps the override model.
Also fixed here: `AgendulaTaskProviderTest` failed on `release/v1.3.1` whenever Agendula ran on an external provider, because `ProviderWriter` checked the active store first. Read-only tables are now refused as such whichever store is active (one exhaustive `when` per operation), and the two tests that check value errors skip when the provider takes no writes at all.
Tests: `RoomTasksDataSourceTest` covers each case above. There is also a migration test, a `ProviderWriterTest` for reopening through the provider, and `RoomSyncStoreAdvancesTest` (full flavour) for the sync discard. The full on-device suite (223 tests) passes on the emulator, and the unit tests pass for both flavours.
Closes #137
Co-authored-by: Jean-Luc Makiola <business@jeanlucmakiola.de>
Reviewed-on: https://codeberg.org/jlmakiola/agendula/pulls/144
Jean-Luc Makiolaandmakiolaj
68495a936c