Server settings → People: a deactivated account keeps getting reminders, webhook posts and syncs #575

New issue

Closed

opened 2026-10-01 10:47:46 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:47:46 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, checking which scheduler queues skip deactivated accounts, and confirmed with a probe on the snapshot.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The code is now at core/server_views.py:234-256 (PersonActiveView); the other locations have not moved.

Server settings → People deactivates an account ("nothing deleted, no sign-in"), and two of the scheduler's announcers skip such accounts with owner__is_active=True. The others do not: due reminders are still announced to every notifier the account configured, queued webhook rows are still posted, sync connections still dial their servers with the stored credentials, and document copies still go to external stores.

Where:
- notifications/management/commands/send_due_reminders.py:47-51, announce_due_reminders: filters only outstanding(), due_at__lte and notified_at__isnull.
- notifications/webhooks.py:77-90, pending: no owner filter.
- plugins/syncing.py:98-106, due_connections: Connection.objects.filter(kind="sync", enabled=True).
- documents/archiving.py:173-189, pending_copies: no owner filter.
- notifications/service.py:60: Connection.objects.for_user(user) checks only is_authenticated, which is always true for a saved user, so notify itself does not stop it.
- The ones that do skip: applications/quiet.py:71 and jobs/closing.py:80. Deactivation is core/server_views.py:233-255, PersonActiveView.
What happens: an administrator deactivates an account, for example of somebody who has left, or one they believe is compromised. On the next pass each due reminder of that account is stamped and sent by email, Apprise, browser push and webhook; in the probe, a reminder of an inactive owner was announced and its webhook row was queued and returned by pending(). Calendar and mail syncs keep running on the account's behalf.
Why it matters: deactivation is the administrator's switch for "this account is no longer in use", and Postulo keeps making outbound requests and sending mail for it. The two announcers that already filter show the intended rule; the rest drifted from it.
Fix: filter on the owner being active in each queue: owner__is_active=True in announce_due_reminders, webhooks.pending, due_connections and pending_copies, leaving the rows in place so reactivation resumes them. As a backstop, have notify return 0 for an inactive user, which covers every announcer and errand at once.

Done when

A test in tests/test_scheduler.py deactivates the owner of a due reminder and expects announce_due_reminders() to return (0, 0) and leave notified_at empty.
Tests in tests/test_webhooks.py, tests/test_syncs.py and tests/test_stores.py expect an inactive owner's rows and connections to be left out of pending(), due_connections() and pending_copies().

Found on 2026-09-29 in a read-only review of postulo at 95348908d, checking which scheduler queues skip deactivated accounts, and confirmed with a probe on the snapshot. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The code is now at `core/server_views.py:234-256` (`PersonActiveView`); the other locations have not moved. *Server settings → People* deactivates an account ("nothing deleted, no sign-in"), and two of the scheduler's announcers skip such accounts with `owner__is_active=True`. The others do not: due reminders are still announced to every notifier the account configured, queued webhook rows are still posted, sync connections still dial their servers with the stored credentials, and document copies still go to external stores. - **Where:** - `notifications/management/commands/send_due_reminders.py:47-51`, `announce_due_reminders`: filters only `outstanding()`, `due_at__lte` and `notified_at__isnull`. - `notifications/webhooks.py:77-90`, `pending`: no owner filter. - `plugins/syncing.py:98-106`, `due_connections`: `Connection.objects.filter(kind="sync", enabled=True)`. - `documents/archiving.py:173-189`, `pending_copies`: no owner filter. - `notifications/service.py:60`: `Connection.objects.for_user(user)` checks only `is_authenticated`, which is always true for a saved user, so `notify` itself does not stop it. - The ones that do skip: `applications/quiet.py:71` and `jobs/closing.py:80`. Deactivation is `core/server_views.py:233-255`, `PersonActiveView`. - **What happens:** an administrator deactivates an account, for example of somebody who has left, or one they believe is compromised. On the next pass each due reminder of that account is stamped and sent by email, Apprise, browser push and webhook; in the probe, a reminder of an inactive owner was announced and its webhook row was queued and returned by `pending()`. Calendar and mail syncs keep running on the account's behalf. - **Why it matters:** deactivation is the administrator's switch for "this account is no longer in use", and Postulo keeps making outbound requests and sending mail for it. The two announcers that already filter show the intended rule; the rest drifted from it. - **Fix:** filter on the owner being active in each queue: `owner__is_active=True` in `announce_due_reminders`, `webhooks.pending`, `due_connections` and `pending_copies`, leaving the rows in place so reactivation resumes them. As a backstop, have `notify` return 0 for an inactive user, which covers every announcer and errand at once. ## Done when - A test in `tests/test_scheduler.py` deactivates the owner of a due reminder and expects `announce_due_reminders()` to return `(0, 0)` and leave `notified_at` empty. - Tests in `tests/test_webhooks.py`, `tests/test_syncs.py` and `tests/test_stores.py` expect an inactive owner's rows and connections to be left out of `pending()`, `due_connections()` and `pending_copies()`.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:46 +00:00

tiagoagueda added the

tier

bug

labels

2026-10-01 10:47:46 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 02:35:50 +00:00

Stop sending on behalf of a deactivated account

tiagoagueda closed this issue

2026-10-04 02:35:50 +00:00