Code review of the one-visibility-model fix (#75) found the reconciliation
reaching further than it should and the read-only case falling through it.
The migration switched calendars *on* to keep the upgrade invisible, but
"not disabled in Calendula" is the default for every calendar, including ones
the user deliberately hid in Google Calendar, Etar or DAVx5 — those would
reappear there and start firing reminders from a switch the user never touched.
Its sync_events guard didn't hold either: an ACCOUNT_TYPE_LOCAL calendar another
app created can sit at sync_events=0 while holding real device-local events. The
reconcile now only hides, and a one-time notice explains that visibility follows
the device and where to change it, instead of quietly rewriting other apps'
state.
Only READ_CALENDAR gates the app, so a read-only install could not write the
flag at all: every calendar it had switched off came back with its events and
its reminders, and the switch couldn't undo it. Those switch-offs are kept
app-side now (the retired disabled-set key, re-read under a new name), folded
into the visibility every consumer reads, and drained into the provider entry by
entry once WRITE_CALENDAR arrives — which also makes a part-applied run resumable
without re-applying a switch the user has since flipped by hand.
Also: restore the ReminderNotifier.post gate, the one path a snooze re-shown
from our own alarm passes; move the whole reconcile inside its try/catch, so a
damaged preferences file can't crash the process at launch; share one Calendars
query per provider tick across the flows that need it; and give the reworded
Settings hint new keys, so five locales stop rendering the retired app-only
wording.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reminders never fired for a calendar hidden at system level and nothing hinted
at it: the provider only schedules reminder alarms for Calendars.VISIBLE=1,
while Calendula filtered with its own disabledCalendarIds pref and parsed
isVisibleInSystem without ever using it — two models that could disagree
indefinitely.
Settings → Calendars now writes Calendars.VISIBLE, one calendar per update
(CalendarProvider2 skips its own checkNextAlarm() reschedule for any selection
that isn't _id=), and every display predicate reads isVisibleInSystem. The
drawer's filter sheet stays a purely in-app declutter and still leaves reminders
alone.
With VISIBLE=0 the provider creates no alert rows, so there is nothing left to
suppress: the disabled-calendar gates, SuppressedReminderStore and the re-enable
recovery are gone. A one-shot migration reconciles the retired set with the app's
state winning — enabled in-app and syncing gets shown, disabled gets hidden,
everything else untouched — so the upgrade changes nothing the user sees.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reminders never fire for a calendar hidden at system level, and nothing in
the app hints at it: the provider only schedules reminder alarms for
Calendars.VISIBLE=1, while Calendula filters with its own disabledCalendarIds
pref and parses isVisibleInSystem without ever using it.
Captures the decision to collapse to one model (the Settings → Calendars
toggle becomes Calendars.VISIBLE, the filter sheet stays app-local), the
verified provider behaviour behind it — including that VISIBLE is device-local
and that a non-`_id=` selection makes the provider skip its own
checkNextAlarm() reschedule — the narrowed migration, and what gets deleted.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
