Removing another user from a conversation creates an unclearable notification

How to reproduce

  1. Create a temp user. (Don’t forget you can use the plus trick. So username+whatever@gmail.com.)
  2. Send a message to the temp user. (This will create a high priority notification.)
  3. Remove the temp user from the personal message. (Hopefully your spelling is better than mine.)
  4. If you are an admin, impersonate the temp user and try to clear the notification. (Whah ha ha!)

Mitigation

An admin can delete the message, which will clear the notification. The trick is finding notification. I manager it user this query:

-- [params]
-- int :user_id 

SELECT * 
from notifications 
where user_id = :user_id
      and high_priority
      and not read

I don’t think the user can clear the notification on their own since they can’t visit the PM even if they have the URL.

Possible solution

When someone is removed from a conversation, also remove the notification.

So if I were to remove someone then they will get a notification but if I remove that then they shouldn’t get it?

Can the user just click the Dismiss button on the notification menu?

Oh good grief. I didn’t even know that button existed. It does clear the notification now that I know it exists.

Oh ok, I now see what your saying here.

For what it’s worth, I still think the notification should be deleted/cleared if the recipient is no longer able to view the message. Having a backstop (the “Dismiss” button) is good, but it’s still a bit like gaslighting the user that the notification sticks around. In addition, the button dismisses everything, which might not be what a user wants. (Though, in fairness, most people will only notice the problem if they’ve cleared all their other notifications the normal way.)

Hi Jon, it sure is a minor inconvenience that we can get rid of very easily, but I couldn’t repro it:

The notification inside the user menu is also removed as soon as we click on the PM (which leads to a “Oops! That page doesn’t exist or is private.” page since the account doesn’t have access to it).

Did I miss something in your repro steps?

I tested with a moderator on our production system and the “Oops! That page doesn’t exist or is private.” page didn’t clear the notification. But our production system is still on 2.9.0.beta14. Just now when I did that test on my own Discourse server, which is 3.1.0.beta2, the notification does go away when the recipient tries the URL. So maybe that part of the problem has already been fixed?

However, I don’t see any way for the recipient to see the message after they have been removed from the PM thread. I could pass the URL to the recipient out-of-band, but that’s not likely to happen in a real situation. Instead, the recipient will have a notification without any way to know the URL or even who initiated it. Here’s a screenshot from a brand new account that has been notified of a PM that they can’t access:

This is on 3.1.0.beta2. You can see the notification added if you have another window open on the temp user’s view. But there’s no item to select after the user has been removed.

PM

I don’t see “A test pm” in either the video or the screenshot of the Dummy user’s view. I found it a lot simpler to debug with a completely fresh dummy user.

You’re using the Legacy notification menu, which is also linked to the notifications on the avatar menu.

I can repro your issue with the Legacy notification menu.

Notifications have indeed been reworked and the Legacy notification menu will be unsupported and removed in the future.

I suggest you set the navigation menu setting to “Sidebar” or “Header Dropdown” :slight_smile:

어제 이 같은 버그를 보고했습니다(이 주제를 찾지 못했습니다). Legacy 메뉴 탐색과 관련이 있어 보이며, 2.8의 최신 버전에서도 이미 존재하고 있었습니다.

‘모두 무시’ 버튼은 해당 알림이 유일한 알림인 경우 작동하지 않는 것 같습니다. 그 경우 버튼이 비활성화되거든요. 알림이 여러 개일 때는 작동할 수 있겠지만, 그럴 경우 관련이 있을 수 있는 내용까지 무시하게 됩니다.

현재 상태로는 사용자들이 혼란을 겪거나/또는 좌절하게 됩니다. 불평하는 소수의 사용자에게는 버튼을 사용하라고 말해줄 수 있지만, 이는 일부 경우에만 작동합니다. 이 문제를 #contribute:bug으로 이동하는 것이 더 나은 것 아닙니까?

#contribute:bug에서 유사한 동작에 대한 새 토픽이 열렸으며, 해당 동작에 대해 더 자세한 설명이 포함되어 있습니다:

따라서 이 토픽은 해결된 것으로 표시하고 다른 토픽을 우선시하여 닫겠습니다. 사소한 문제이지만, 여러 번 보고되었기 때문에 #contribute:bug에 있는 것이 더 적절해 보입니다.