우선순위/심각도 : 낮음
플랫폼 : Windows/Android
설명 : Windows와 Android에서 읽지 않은 개인 메시지 알림이 표시되지만, 이를 클릭하면 페이지가 존재하지 않거나 비공개라고 표시됩니다.
메시지를 읽을 수 없으므로 알림을 해제하는 방법이 없는 것 같습니다.
재현 단계 : 재현을 시도해 보지는 않았지만, 발생한 상황은 메시지가 읽지 않은 상태로 남아있을 때 수신자에서 제외되어 더 이상 메시지를 볼 권한이 없게 된 것입니다.
2개의 좋아요
Moin
6월 13, 2024, 9:22오후
2
Does the number disappear when you reload the site?
That’s what I did to get rid of the notification for a like when someone has liked one of my posts and deleted it immediately afterwards.
1개의 좋아요
Moin
6월 13, 2024, 9:37오후
4
I was able to reproduce the issue.
Clicking Dismiss removed the notification
1개의 좋아요
sam
(Sam Saffron)
6월 14, 2024, 3:51오전
5
If you can not dismiss it from the top, maybe try dismissing it from your profile, notification tab (there is a dismiss all) ?
I guess there are 2 questions here
How did the bug happen (my guess, maybe being kicked out of a PM can trigger this)?
How to get this annoying notification to go away (hopefully the dismiss stuff helps)
2개의 좋아요
Moin
6월 14, 2024, 6:04오전
6
I followed the steps from the first post
Send a message to a user
Remove the user from the message
Log in as this user
Get rid of the notification by dismissing all notifications
2개의 좋아요
Moin
8월 29, 2025, 4:29오후
7
This still happens, and it is still difficult to get rid of the notification. In particular, you cannot dismiss the single notification, so you first have to check all the other notifications caused by messages.
To some extent, this is even a security vulnerability, as the user should no longer have access to the title of the message.
2개의 좋아요
sam
(Sam Saffron)
8월 31, 2025, 11:43오후
8
I put a note for the team to triage in the next few weeks.
2개의 좋아요
Moin
12월 8, 2025, 5:23오후
10
이 문제에 대해 새로운 소식은 없나요?
PM에서 제거한 사용자가 여전히 제목 변경 사항을 볼 수 있다는 점은 여전히 우려스럽습니다. 이는 개인 메시지로 전환한 주제를 다시 이름 변경하는 제 능력에 영향을 미칩니다. 제가 사용자를 제거하는 데는 이유가 있으며, 새 제목에 대한 접근 권한을 그들에게 주지 않기를 원합니다.
2개의 좋아요
사실상 PM에서 사용자를 제거할 때(직접 제거하거나 그룹을 통해 제거하는 경우) 일부 “정리” 처리 경로를 누락하고 있었습니다.
main ← fix-phantom-notification-after-being-removed-from-a-pm
closed 03:07PM - 13 Feb 26 UTC
Users were experiencing "phantom notifications" - seeing an unread notification … count but being unable to find or dismiss the notifications. This happened because notification counts don't verify PM access, while the notification list filters out inaccessible ones.
The root cause was that notifications weren't being deleted when users lost PM access through various paths: being removed directly, having their group removed, or being removed from a group.
This fix:
- Adds `Notification.orphaned_pm_notifications` scope to identify notifications for PMs the user can no longer access
- Calls cleanup from `Topic#remove_allowed_user`, `Topic#remove_allowed_group`, `Group#remove`, and `Group#bulk_remove`
- Adds cleanup to `Notification.ensure_consistency!` as a safety net
- Includes a migration to clean up existing orphaned notifications
Report - meta/t/311995
2개의 좋아요
Moin
12월 9, 2025, 11:19오전
14
Moin
1월 12, 2026, 8:41오후
15
이 이슈가 열려 있는 지 좀 되었습니다. 이 문제를 해결하기 위해 추가로 필요한 것이 있는지, 아니면 아직 검토 및 병합할 시간이 없었는지 확인해 주실 수 있나요?
알림 개수와 관련된 여러 일관성 문제의 근본 원인을 수정하는 작업을 진행해 왔으며, 그 결과 위에 올린 PR은 이 PR으로 대체되었습니다.
main ← fix/stuck-notification-count
closed 02:46PM - 24 Jun 26 UTC
Notification badge counts could get "stuck" — showing a number higher
than the a… ctual visible notifications. This happened because count
queries used lightweight SQL (only filtering deleted topics), while
display queries applied full access control via Guardian. When a user
lost access to a topic — removed from a group/PM, or category
permissions changed — the notification persisted in counts but was
filtered from the displayed list.
Additionally, the `visible` scope had a logic error: the LEFT JOIN
condition `topics.id IS NULL OR topics.deleted_at IS NULL` incorrectly
included notifications for hard-deleted topics.
The fix introduces `NotificationQuery` (following the `BookmarkQuery`
pattern) — a centralized class that handles all notification filtering
at the SQL level, ensuring counts always match displayed notifications.
Access control uses a CASE on topic archetype: PMs check
topic_allowed_users + topic_allowed_groups; regular topics check
category read_restricted against the user's secure_category_ids. Shared
drafts are excluded when the user lacks access. Admins without
suppress_secured_categories_from_admin skip all checks. Badge
notifications are handled via Ruby post-processing when enable_badges
is false.
To prevent DB bloat from orphaned notifications, model callbacks
enqueue DeleteInaccessibleNotifications when access is revoked:
- TopicAllowedUser after_destroy — enqueues with topic_id
- TopicAllowedGroup after_destroy — enqueues with topic_id
- GroupUser after_destroy — enqueues with user_id + group_id
- Category after_update — enqueues with category_id when permissions change
The job supports three modes: topic_id (checks each user via Guardian),
category_id (iterates topics, delegates to topic_id mode), and
user_id + group_id (finds affected topics, bulk-deletes where user
lost access).
Redo of #27589.
Ref - t/121464
1개의 좋아요
이 작업은 진행 중이던 시점에 해당 영역에서 많은 변경 사항이 동시에 이루어지면서 상당히 지연되었습니다. 그 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개의 좋아요