makiolaj
b933705c84
Re-authentication reported success for work it never did. The branch took appPassword and dropped `found` and `selected` on the floor, so a user whose account had 401'd walked the whole add flow, ticked collections, and was shown Done — while no newly-ticked list was created, and a moved principal or corrected username was discarded, so a relocated account could never be repaired. It also never called accounts.add, so an account deleted in Android Settings (nothing listens for LOGIN_ACCOUNTS_CHANGED) stayed absent from Settings for ever while syncing happily via WorkManager, and every later add answered AlreadyExists. Unticked lists are still left attached, deliberately: the picker pre-ticks what is *writable*, not what this account already holds, so detaching would stop syncing a read-only share over a default nobody chose. Remove-then-re-add duplicated every list. remove() leaves them behind as device-only lists on purpose and create() always inserted, so the user got their old Personal full of tasks beside a freshly synced Personal holding the same tasks from the server — the outcome the comment next to it names as the one to avoid. A collection whose href is already on the device is re-attached now, keeping its name, colour, ordering and tasks and losing only a cursor that belonged to the account that is gone. Rollback follows: it deletes what this attempt created and lets the FK return a re-attached list to being device-only. An account in the system with no Room row could not be removed from inside the app — accounts.remove's result is ignored and find returns null while the device is locked, so the pair can come apart, and every later add then answered AlreadyExists with the accounts screen driven off Room. That state is treated as an orphan to clean up. create()'s tail is uncancellable, like remove()'s: a back gesture during "Adding the account" left the row and its lists with no credential and no system account, where the rollback never runs, needsSignIn is false so re-auth will not fire, and every retry answers AlreadyExists. remove() forgets the quarantine counts as well as the cadence cursors — same keys, same globality, and a list re-attached to a new account would otherwise inherit a resource that is skipped for ever. And NeedsAuthentication's doc claimed the caller widens a credential allowlist with its hosts. Nothing does, and nothing should without the user's say-so; it says what the list is actually for.
Agendula
A modern Material 3 Expressive task app for Android.
Keeps your tasks on your device, or on top of a tasks provider you already use.
Open standards, no account required.
Agendula is the task-list sibling to Calendula.
Where Calendula is a pure front-end over Android's CalendarContract, Agendula
keeps its own store, designed around RFC 5545's VTODO — the same tasks DAVx5
(and SmoothSync, DecSync, …) sync out of your CalDAV server. It can also read and
write a tasks provider you already have, for anyone already syncing that way.
The name rhymes with its sibling on purpose: Agendula is agenda — Latin for
“things to be done” — given Calendula's -ula ending. Calendula keeps your days;
Agendula keeps your to-dos. (A Calendula flower head is botanically a cluster of
many small florets — so the two apps are florets of one bloom.)
Where your tasks live — your choice
| Where | Sync | Needs | |
|---|---|---|---|
| On your device (default) | Agendula's own database | none yet — CalDAV sync of our own is planned | nothing. No account, no permissions, no other app |
| In a provider you already use | OpenTasks or tasks.org | whatever syncs it for you — DAVx5 and friends | that app installed, and its read/write permission |
Agendula's own store is an ordinary app database — nothing is published to other apps, so there is no authority to clash over and no permission to grant. It coexists with OpenTasks rather than replacing it: installing one never breaks the other, and if you already sync through a provider, that keeps working exactly as it did.
Recurring tasks are expanded per RFC 5545, and everything the schema does not model is round-tripped verbatim rather than dropped — so passing your tasks through Agendula does not quietly lose fields a server sent.
Your tasks are exportable as standard iCalendar .ics files at any time, because
data you can't take with you isn't really yours.
Status: backend complete, UI catching up. Storage, reads and writes, smart-list filtering, a self-scheduled reminder engine, and export are built and unit-tested. The Material 3 Expressive screens are being built on top, one at a time — the storage-mode picker and export screen are not there yet. See
docs/ROADMAP.mdfor status,docs/ARCHITECTURE.mdfor how it's built, anddocs/STORAGE-AND-SYNC.mdfor why storage works the way it does.
Sync sources (by design)
In external-provider mode Agendula works with anything that writes to that provider — DAVx5 (CalDAV), SmoothSync, CalDAV-Sync, DecSync CC, or any Android sync adapter — because it builds on the provider, not on any one sync app. Google Tasks / Microsoft To Do are out of scope by design (proprietary; they would mean owning a sync stack). Open standards — CalDAV / iCalendar / DecSync — are the lane.
Translations
Agendula ships in English so far, and would like not to. Translations are managed on a self-hosted Weblate, and partial ones are fine — an untranslated string simply falls back to English.
No coding needed: register on the Weblate server, pick (or request) a language, and translate the strings in your browser. You can also reach this link in the app from the top of Settings → App language.
License
MIT — see LICENSE.