우선순위/심각도 : 낮음
플랫폼 : 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
Is there any news on this?
I still find it concerning that users I remove from a PM can still see title changes. This affects my ability to rename a topic that I convert into a personal message. There is a reason why I remove the user, and I don’t want them to have access to the new title.
2개의 좋아요
I’ll see if i can reproduce
2개의 좋아요
We were indeed missing some “cleanup” path when removing users from PMs (either directly or through a group).
https://github.com/discourse/discourse/pull/36557
2개의 좋아요
Moin
12월 9, 2025, 11:19오전
14
Moin
1월 12, 2026, 8:41오후
15
This has been open for a while now. Is there anything else needed for this, or has there simply been no time to review and merge it so far?
I have been working on fixing the root cause of several related inconsistencies regarding notification counts so my above PR has been superseded by this one
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개의 좋아요