Prioridade/Gravidade : baixa
Plataforma : Windows/Android
Descrição : No Windows e no Android, estou vendo uma notificação de mensagem pessoal não lida, mas quando clico nela, diz que a página não existe ou é privada.
Parece não haver como eu limpar a notificação, já que não consigo ler a mensagem.
Etapas para reproduzir : Não tentei reproduzir, mas o que aconteceu foi que fui removido como destinatário enquanto a mensagem estava não lida, então não tenho mais permissão para visualizar a mensagem.
2 curtidas
Moin
Junho 13, 2024, 9:22pm
2
O número desaparece quando você recarrega o site?
Foi o que eu fiz para me livrar da notificação de um like quando alguém curtiu uma das minhas postagens e a excluiu imediatamente depois.
1 curtida
Moin
Junho 13, 2024, 9:37pm
4
Consegui reproduzir o problema.
Clicar em Dismiss removeu a notificação.
1 curtida
sam
(Sam Saffron)
Junho 14, 2024, 3:51am
5
Se você não conseguir dispensá-la de cima, talvez tente dispensá-la do seu perfil, aba de notificações (há um “dispensar tudo”)?
Acho que há 2 perguntas aqui
Como o bug aconteceu (minha suposição, talvez ser expulso de um PM possa desencadear isso)?
Como fazer essa notificação irritante desaparecer (espero que as opções de dispensar ajudem)
2 curtidas
Moin
Junho 14, 2024, 6:04am
6
Segui os passos do primeiro post
Enviar uma mensagem para um usuário
Remover o usuário da mensagem
Entrar como este usuário
Livrar-se da notificação dispensando todas as notificações
2 curtidas
Moin
Agosto 29, 2025, 4:29pm
7
Isso ainda acontece e ainda é difícil se livrar da notificação. Em particular, você não pode dispensar a notificação única, então primeiro precisa verificar todas as outras notificações causadas por mensagens.
Até certo ponto, isso é até mesmo uma vulnerabilidade de segurança, pois o usuário não deve mais ter acesso ao título da mensagem.
2 curtidas
sam
(Sam Saffron)
Agosto 31, 2025, 11:43pm
8
Coloquei um lembrete para a equipe triar nas próximas semanas.
2 curtidas
Moin
Dezembro 8, 2025, 5:23pm
10
Há alguma notícia sobre isso?
Ainda acho preocupante que usuários que removo de uma MP ainda possam ver alterações de título. Isso afeta minha capacidade de renomear um tópico que converto em uma mensagem pessoal. Há um motivo pelo qual removo o usuário, e eu não quero que ele tenha acesso ao novo título.
2 curtidas
Vou ver se consigo reproduzir
2 curtidas
Estávamos de fato perdendo um caminho de “limpeza” ao remover usuários de MPs (diretamente ou através de um grupo).
main ← fix-phantom-notification-after-being-removed-from-a-pm
opened 10:58AM - 09 Dec 25 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 curtidas
Moin
Dezembro 9, 2025, 11:19am
14
Acho que isso também corrigirá Sticky unread reply notification .
Moin
Janeiro 12, 2026, 8:41pm
15
Isto está aberto há algum tempo. Algo mais é necessário para isto, ou simplesmente não houve tempo para revisá-lo e mesclá-lo até agora?
Tenho trabalhado na correção da causa raiz de várias inconsistências relacionadas às contagens de notificações, então meu PR acima foi substituído por este
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 curtida
Isso foi atrasado bastante devido a muitas mudanças na área afetada ao mesmo tempo em que isso estava sendo trabalhado. Esses PRs ficaram obsoletos demais para serem revividos — e também percebi que foi minha própria ação que atrasou isso, pois eu era quem estava fazendo todas as mudanças naquela área. Então, assumi este e acabei de mesclar uma correção.
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)
Acredito que isso esteja correto, e também não tenho certeza se ainda estava quebrado atualmente. De qualquer forma, definitivamente pode ser corrigido após esta mesclagem.
2 curtidas