이 작업은 진행 중이던 시점에 해당 영역에서 많은 변경 사항이 동시에 이루어지면서 상당히 지연되었습니다. 그 PR들은 부활시키기에는 너무 오래된 상태가 되었고, 또한 해당 영역에서 모든 변경 사항을 만든 사람이 저였기 때문에 제가 이 지연의 원인이 된 것도 알게 되었습니다. 그래서 이 작업을 제가 맡아 수정 사항을 병합했습니다.
main ← fix-stranded-notifications-revoked-access
merged 05:50PM - 12 Aug 26 UTC
The notification list Guardian-filters inaccessible topics, but the unread-badge… counter (raw SQL COUNT) does not. When a user lost PM access, stale notification rows kept inflating the badge — the menu showed nothing new, but the count wouldn't clear.
Discourse already has `Jobs::DeleteInaccessibleNotifications` (used by `TopicConverter` and `PostMover`). This PR:
- Wires it into `Topic#remove_allowed_user` (inline, Guardian-guarded so users with group-based access are preserved), `Topic#remove_allowed_group`, and `GroupManager#remove/bulk_remove`.
- Narrows the `GroupManager` enqueue to topics where removed users actually have notifications, and passes `user_ids` so the job scopes its work — prevents fan-out when a large group sits on many PMs.
- Rewrites the job: Guardian-check once per user (not per notification), single batched `delete_all`, one publish_notifications_state` per user.
- Adds a post-deploy backfill migration to clean up existing orphaned PM notifications.
Category-permission, trust-level, and direct `GroupUser#destroy` paths (SSO, auto-groups) are left as follow-ups.
[`/t/311995`](https://meta.discourse.org/t/cant-clear-unread-notification-after-being-removed-from-a-pm/311995)
[`/t/384961`](https://meta.discourse.org/t/sticky-unread-reply-notification/384961)
그렇다고 믿고 있으며, 현재 여전히 깨져 있는 상태인지도 확신이 서지 않습니다. 어쨌든, 이 병합 이후 반드시 수정될 것입니다.
2개의 좋아요