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
  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!)


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 

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.

1 Like

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

1 Like

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:

Screenshot 2023-03-08 at 9.25.30 AM

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.


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:


Yesterday I reported this same bug (didn’t find this topic). It seems dependent on the the Legacy menu navigation, and it was already present the latest versions of 2.8.

The Dismiss All button workaround doesn’t seem work if that’s the only notification left, as the button is disabled in that case. Perhaps it works if there are more notifications — but then the person may be dismissing things that may be relevant.

As is, users will just get confused and/or frustrated. The few that complain may be told to use the button but that will only work in some cases. Shouldn’t this be moved to bug perhaps?

1 Like

A new topic on similar behavior was opened in bug with more detailed instructions on this behavior:

So I’ll close this one marked as solved in favor of the other one. It’s a minor issue, but having it in bug feels more appropriate especially since it has been reported multiple times.