I think this was resolved. I nuked Discourse anyway so it's effectively resolved until another report shows up.

An issue arose when a user loads a page of notifications which include stories they don't have permission to view.

I deployed this and nothing blew up, presuming this is resolved.

When users are @mentioned on an object, render their name in a disabled style if they've been muted.

A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.

FWIW I appreciate and use the mute feature (though only occasionally)

After D19384, we'll automatically mark these "phantom" notifications as read when you open the menu to review them:

I largely agree. This is getting leeway because it's backed by support mana (PHI126 basically just asks for this feature, verbatim). I think the actual change in D19033 is small enough that I don't feel too bad about giving this a shot, but I'd like this feature to see significant use and not generate a lot of confusion/support load if it's going to stay in the upstream. I'm also more comfortable trying this because it's very easy to revert.

For what it's worth, I think the Mute feature adds a lot of complexities to the system, in excess to the norms of the last few years:

• Code to handle it in the sending mechanism
• Prioritizing this feature against any other notify feature (like T9031)
• UI to show the to the muting user (on the object and in /mail/?)
• UI to show to other users that this user will not be notified (What if all members of a project are muting a thread?)
• Can a mailing list/project mute a topic?
• "why did I not receive this notification?" - there's still some issues about this - novice users don't know/understand /mail/, and admins can't see this for them. I suspect this question will require a written checklist somewhere.

If this feature doesn't see much use, I'd like to remove or deemphasize it (for example, by moving it to a keystroke or removing the UI and just providing access via !mute) at some point since I think UI space in the curtain is premium real estate. This doesn't need to be 200 mutes per user per day, but I could imagine this seeing essentially zero use.

Could this be closed now that Phab supports this? (in /settings/user/Username/page/notifications/)

This is also affecting other persistent sticky notifications, notably "Read-Only Mode" and "High Security Mode". I need "Read-Only" mode for PHI36 so I'll take a look at this.

Should be quick to implement.

I'm going to merge this into T12963, which isn't exactly the same but overlaps this substantially. It's possible we'll pursue a more narrow "vacation review" mode eventually, but we'd want to finish T12963 first and make sure it didn't adequately address this problem on its own.

It's discoverable in settings just fine.

What if they're on the page, is that notification annoying? I love click that little guy.

+1, we've also had a handful of users request this as a per-user preference.

We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.

Arguments against: