Priority/Severity : low
Platform : Windows/Android
Description : On Windows and on Android, I’m seeing an unread personal message notification, but when I click on it, it says the page doesn’t exist or is private.
There seems to be no way for me to clear the notification since I can’t read the message.
Reproducible steps : I haven’t tried to reproduce it, but what happened was I was removed as a recipient while the message was unread, so I no longer have permission to view the message.
2 likes
Moin
13 juni 2024 om 21: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 like
Moin
13 juni 2024 om 21:37
4
I was able to reproduce the issue.
Clicking Dismiss removed the notification
1 like
sam
(Sam Saffron)
14 juni 2024 om 03: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 likes
Moin
14 juni 2024 om 06: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 likes
Moin
29 augustus 2025 om 16:29
7
Dit gebeurt nog steeds en het is nog steeds moeilijk om de melding kwijt te raken. Je kunt de enkele melding niet afwijzen, dus je moet eerst alle andere meldingen van berichten controleren.
Tot op zekere hoogte is dit zelfs een beveiligingslek, aangezien de gebruiker geen toegang meer mag hebben tot de titel van het bericht.
2 likes
sam
(Sam Saffron)
31 augustus 2025 om 23:43
8
Ik heb een notitie voor het team geplaatst om de komende weken te triageren.
2 likes
Moin
8 december 2025 om 17: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 likes
I’ll see if i can reproduce
2 likes
We were indeed missing some “cleanup” path when removing users from PMs (either directly or through a group).
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 likes
Moin
9 december 2025 om 11:19
14
Moin
12 januari 2026 om 20: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
approved 05:24PM - 06 Feb 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 like