Priorità/Gravità : bassa
Piattaforma : Windows/Android
Descrizione : Sia su Windows che su Android, vedo una notifica di messaggio personale non letto, ma quando ci clicco sopra, dice che la pagina non esiste o è privata.
Sembra non esserci modo di eliminare la notifica poiché non posso leggere il messaggio.
Passaggi per la riproduzione : Non ho provato a riprodurlo, ma quello che è successo è che sono stato rimosso come destinatario mentre il messaggio non era letto, quindi non ho più il permesso di visualizzare il messaggio.
2 Mi Piace
Moin
13 Giugno 2024, 9:22pm
2
Il numero scompare quando ricarichi il sito?
È quello che ho fatto per eliminare la notifica di un like quando qualcuno ha messo mi piace a uno dei miei post e l’ha eliminato subito dopo.
1 Mi Piace
Moin
13 Giugno 2024, 9:37pm
4
Sono riuscito a riprodurre il problema.
Fare clic su Dismiss ha rimosso la notifica.
1 Mi Piace
sam
(Sam Saffron)
14 Giugno 2024, 3:51am
5
Se non riesci a rimuoverla dall’alto, forse prova a rimuoverla dal tuo profilo, scheda notifiche (c’è un’opzione per rimuovere tutto)?
Suppongo che qui ci siano 2 domande
Come è successo il bug (la mia ipotesi, forse essere espulsi da un PM può attivare questo)?
Come far sparire questa fastidiosa notifica (sperando che le opzioni di rimozione aiutino)
2 Mi Piace
Moin
14 Giugno 2024, 6:04am
6
Ho seguito i passaggi dal primo post
flarsric:
Passaggi riproducibili : Non ho provato a riprodurlo, ma quello che è successo è che sono stato rimosso come destinatario mentre il messaggio non era stato letto, quindi non ho più il permesso di visualizzare il messaggio.
Invia un messaggio a un utente
Rimuovi l’utente dal messaggio
Accedi come questo utente
Elimina la notifica eliminando tutte le notifiche
2 Mi Piace
Moin
29 Agosto 2025, 4:29pm
7
Questo accade ancora ed è ancora difficile liberarsi della notifica. In particolare, non è possibile ignorare la singola notifica, quindi è necessario prima controllare tutte le altre notifiche causate dai messaggi.
In una certa misura, questa è persino una vulnerabilità di sicurezza, poiché l’utente non dovrebbe più avere accesso al titolo del messaggio.
2 Mi Piace
sam
(Sam Saffron)
31 Agosto 2025, 11:43pm
8
Ho lasciato una nota al team per effettuare il triage nelle prossime settimane.
2 Mi Piace
Moin
8 Dicembre 2025, 5:23pm
10
Ci sono novità a riguardo?
Trovo ancora preoccupante che gli utenti che rimuovo da un messaggio privato (PM) possano ancora vedere le modifiche al titolo. Ciò influisce sulla mia capacità di rinominare un argomento che converto in un messaggio personale. C’è un motivo per cui rimuovo l’utente e non voglio che abbia accesso al nuovo titolo.
2 Mi Piace
Vedrò se riesco a riprodurlo
2 Mi Piace
Ci mancava effettivamente un percorso di “pulizia” quando si rimuovevano gli utenti dai messaggi privati (direttamente o tramite un gruppo).
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 Mi Piace
Moin
9 Dicembre 2025, 11:19am
14
Penso che questo risolverà anche Sticky unread reply notification .
Moin
12 Gennaio 2026, 8:41pm
15
Questo è aperto da un po’ di tempo. C’è qualcos’altro necessario per questo, o semplicemente non c’è stato tempo per rivederlo e unirlo finora?
Ho lavorato per risolvere la causa principale di diverse incoerenze relative ai conteggi delle notifiche, quindi la mia PR precedente è stata sostituita da questa
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 Mi Piace