Приоритет/Серьезность : низкий
Платформа : Windows/Android
Описание : В Windows и на Android я вижу уведомление о непрочитанном личном сообщении, но при нажатии на него сообщается, что страница не существует или является приватной.
Похоже, нет способа убрать уведомление, так как я не могу прочитать сообщение.
Шаги для воспроизведения : Я не пытался воспроизвести проблему, но, по всей видимости, меня исключили из получателей, пока сообщение оставалось непрочитанным, поэтому у меня больше нет разрешения на его просмотр.
2 лайка
Moin
13.Июнь.2024 21:22:43
2
Исчезает ли число при перезагрузке сайта?
Именно так я избавился от уведомления о лайке, когда кто-то лайкнул один из моих постов и сразу же удалил его.
1 лайк
Moin
13.Июнь.2024 21:37:39
4
Мне удалось воспроизвести проблему.
Нажатие на Закрыть убрало уведомление
1 лайк
sam
(Sam Saffron)
14.Июнь.2024 03:51:21
5
Если вы не можете закрыть уведомление сверху, попробуйте сделать это через свой профиль, во вкладке уведомлений (там есть кнопка «Закрыть все»)?
Похоже, здесь два вопроса:
Как возникла эта ошибка (моя версия: возможно, это сработало после того, как вас исключили из личного сообщения)?
Как избавиться от этого надоедливого уведомления (надеюсь, функция закрытия поможет)
2 лайка
Moin
14.Июнь.2024 06:04:22
6
Sam Saffron, пост:5, тема:311995:
Как возникла эта ошибка (моё предположение: возможно, исключение из личного сообщения может вызвать это)?
Я выполнил шаги из первого сообщения.
flarsric:
Шаги для воспроизведения : Я не пытался воспроизвести это, но произошло следующее: меня исключили из получателей, пока сообщение оставалось непрочитанным, поэтому у меня больше нет разрешения на просмотр сообщения.
Отправьте сообщение пользователю.
Удалите пользователя из сообщения.
Войдите в систему под этим пользователем.
Уберите уведомление, отклонив все уведомления.
2 лайка
Moin
29.Август.2025 16:29:40
7
Это всё ещё происходит, и избавиться от уведомления по-прежнему сложно. В частности, нельзя закрыть отдельное уведомление, поэтому сначала нужно отметить все остальные уведомления, вызванные сообщениями.
В определённой степени это даже уязвимость безопасности, так как пользователь больше не должен иметь доступа к заголовку сообщения.
2 лайка
sam
(Sam Saffron)
31.Август.2025 23:43:45
8
Я оставил заметку для команды, чтобы они разобрали это в ближайшие несколько недель.
2 лайка
Moin
08.Декабрь.2025 17:23:11
10
Есть ли какие-то новости по этому вопросу?
Меня по-прежнему беспокоит, что пользователи, которых я удаляю из личного сообщения, всё ещё видят изменения в заголовке. Это влияет на мою возможность переименовать тему, которую я преобразую в личное сообщение. У меня есть причина удалять пользователя, и я не хочу, чтобы у него был доступ к новому заголовку.
2 лайка
Проверю, смогу ли воспроизвести
2 лайка
Действительно, отсутствовал один из путей «очистки» при удалении пользователей из личных сообщений (либо напрямую, либо через группу).
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
09.Декабрь.2025 11:19:39
14
Moin
12.Январь.2026 20:41:40
15
Это открыто уже довольно давно. Нужно ли что-то ещё по этому поводу или до сих пор просто не было времени проверить и слить?
Я работал над устранением основной причины нескольких связанных несоответствий, касающихся количества уведомлений, поэтому мой предыдущий PR был заменён этим:
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 лайк