A denied notification permission is ignored, and unposted reminders still count as having asked #71

New Issue

Closed

opened 2026-08-20 21:24:13 -05:00 by null · 0 comments

null commented

2026-08-20 21:24:13 -05:00

Owner

What is true now. The POST_NOTIFICATIONS result is discarded: NotificationSettingsScreen.kt:58 passes { viewModel.permissionHandled() } and never looks at the Boolean. The toggle stays visually on with no permission, there is no rationale and no route to system settings. Revocation after the fact is never detected — PeriodNotifier.hasPermission() (core/notifications/.../PeriodNotifier.kt:131-134) is called from nowhere in main. areNotificationsEnabled() is never called at all, so below API 33 the app posts blindly even when the user has switched notifications off.

Worse: PeriodNotifier.notify() returns false when it cannot post (:91-96), and both call sites discard it (ReminderWorker.kt:104, :127) while still calling preferences.recordCheckIn() (:147). With notifications denied, the counter climbs to MAX_CHECK_INS and the app permanently stops asking, having never asked once.

Channels are also created lazily inside notify() (:97), so until a reminder actually fires the channels do not exist in system settings and the user cannot pre-configure or pre-mute them; switching privacy mode does not create the new one.

What to do. Record a check-in only when notify() returned true. Read permission state in the settings ViewModel and refresh it on resume. Do NOT silently revert the toggle on denial — it is the user's stated preference, and rewriting it would make a later grant useless; instead show a row when reminders are on but blocked, with a button to the system notification settings for this app. Create the current mode's channel eagerly when reminders are enabled and when the privacy mode changes.

Traps. ACTION_APP_NOTIFICATION_SETTINGS needs a try/catch for ActivityNotFoundException. Do not request the permission on every toggle — only when it is not already granted. docs/qa/ClaudeQACoverage.md:48 records that denied-permission behaviour has never been tried, so this has no existing coverage to lean on.

Verify: without the notification permission nothing is posted and nothing is counted in ReminderWorkerTest; a denied result keeps the toggle and marks reminders blocked and refresh after the user re-enabled notifications clears the blocked state in a new NotificationSettingsViewModelTest.

**What is true now.** The POST_NOTIFICATIONS result is discarded: `NotificationSettingsScreen.kt:58` passes `{ viewModel.permissionHandled() }` and never looks at the Boolean. The toggle stays visually on with no permission, there is no rationale and no route to system settings. Revocation after the fact is never detected — `PeriodNotifier.hasPermission()` (`core/notifications/.../PeriodNotifier.kt:131-134`) is called from nowhere in main. `areNotificationsEnabled()` is never called at all, so below API 33 the app posts blindly even when the user has switched notifications off. Worse: `PeriodNotifier.notify()` returns `false` when it cannot post (`:91-96`), and both call sites discard it (`ReminderWorker.kt:104`, `:127`) while still calling `preferences.recordCheckIn()` (`:147`). With notifications denied, the counter climbs to `MAX_CHECK_INS` and the app permanently stops asking, having never asked once. Channels are also created lazily inside `notify()` (`:97`), so until a reminder actually fires the channels do not exist in system settings and the user cannot pre-configure or pre-mute them; switching privacy mode does not create the new one. **What to do.** Record a check-in only when `notify()` returned true. Read permission state in the settings ViewModel and refresh it on resume. Do NOT silently revert the toggle on denial — it is the user's stated preference, and rewriting it would make a later grant useless; instead show a row when reminders are on but blocked, with a button to the system notification settings for this app. Create the current mode's channel eagerly when reminders are enabled and when the privacy mode changes. **Traps.** `ACTION_APP_NOTIFICATION_SETTINGS` needs a try/catch for `ActivityNotFoundException`. Do not request the permission on every toggle — only when it is not already granted. `docs/qa/ClaudeQACoverage.md:48` records that denied-permission behaviour has never been tried, so this has no existing coverage to lean on. Verify: `without the notification permission nothing is posted and nothing is counted` in `ReminderWorkerTest`; `a denied result keeps the toggle and marks reminders blocked` and `refresh after the user re-enabled notifications clears the blocked state` in a new `NotificationSettingsViewModelTest`.