Can't hide items on Special:Notifications


There's no way to remove an item from Special:Notifications, e.g. by marking it read/trashed/spam. This is particularly troubling given the false positives rate of the notifications, but would be a bug in any case.
The X icon that appears on hover is not a way to remove the item (as I expected) but rather to change preferences on that kind of item; it's not offered for things that can't be disabled, like talk page notifications.

Version: master
Severity: normal
See Also:

bzimport added a project: Notifications.Via ConduitNov 22 2014, 1:28 AM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz46692.
Nemo_bis created this task.Via LegacyMar 29 2013, 11:39 AM
kaldari added a comment.Via ConduitApr 8 2013, 8:55 PM

Special:Notifications is a log of all the notifications you receive. It's not designed to be curatable. (The designers strongly opposed an in-box type model for this.) Most of your interactions with the notifications should theoretically be taking place in the flyout from the red badge icon. That's where it might make more sense to have some remove functionality. Personally, I was thinking that it might be best for the flyout to just show all of your unread notifications (rather than X most recent) and automatically remove them all from the flyout after you close it. There's going to be another meeting on Wednesday to discuss this so let me know if you have any ideas.

Nemo_bis added a comment.Via ConduitApr 8 2013, 8:58 PM

I don't see why a user would need a log in a special page. Can't you use Special:Log for that?

kaldari added a comment.Via ConduitApr 8 2013, 9:12 PM

I think the idea was to make it more friendly than Special:Log. Plus notifications are private and Special:Log is for public logs.

Nemo_bis added a comment.Via ConduitApr 8 2013, 9:23 PM

I've already asked this in the past and heard no clear response: why should notifications be private? I see no reason for it.
I'm not saying to kill Special:Notifications, I just think that the read/unread feature you want for the flyout should be mirrored on the special page in the very same way for user experience consistency.
The user needing to see the full log of notifications including spam and vandalism is an edge case: logs belong to logs and "replace Special:Log" is an extremely bad requirement for the special page. No logging system duplication should be pursued, or the decision will probably have horrible and catastrophic consequences in the future, see the example of the AFT logs and other superstructures.

MZMcBride added a comment.Via ConduitApr 9 2013, 12:38 PM

Anti-abuse measures are required for any feature of this nature. Not only the ability to remove notifications (or mark them as spam), but also the ability to block or ignore notifications from particular sources. If Echo does not have anti-abuse functionality built-in already, it's a blocker to further deployment.

Nemo_bis added a comment.Via ConduitApr 9 2013, 1:15 PM

Sorry, from comment 3 on we're going on a tangent; I moved/clarified my comment at, we should probably continue there (assuming there's something useful worth discussing in it, of course).

kaldari added a comment.Via ConduitApr 9 2013, 5:48 PM

Left some comments at Talk:Echo_(Notifications)/Feature_requirements. Anyway, let's get this bug discussion back on track. What sort of dismiss functionality would you like to see. There are lots of options:

  1. No dismiss functionality
  2. Dismiss individual notification
  3. Dismiss individual notification and present option for dismissing category
  4. Present option for dismissing category or individual notification
  5. Dismiss category
  6. Present option for dismissing category

There's also the possibility of dismissing notifications from particular users or regarding particular pages, but we decided that would overly complicate things since we would need to keep track of a lot of 'unsubscription' data for every user and give them preferences for changing all of those decisions (which would create a lot of complicated UX).

Also, should there be categories of notifications that are not unsubscribable? Right now there are two: 'System' notifications ("Welcome to Wikipedia", "You've been blocked", "You are now an administrator", etc.) and Talk Page Post notifications. For Talk Page Notifications we allow unsubscribing from email, but not from the web notifications. The thought here is that (1) we wanted to mirror the existing talk page notification system (2) we were worried about people accidentally turning off talk page notifications (3) is there ever a legitimate reason to turn off talk page notifications?

matmarex added a comment.Via ConduitSep 2 2013, 10:00 PM

I'm pretty sure this request is about dismissing individual notifications, and I agree that a "dismiss" or "archive" button would be useful.

This would make notifs have three states - unread, read and archived. This is already probably known to users (e.g. GMail does this in their interface) and hardly a very complicated concept.

Special:Notifications could then have a filter by the state for when one decides they want to see the old notifs one more time.

Quiddity added a comment.Via ConduitSep 8 2013, 10:34 PM

There are 2 related requests at which I'd summarize as "Dismissing/removing notifications - a way to remove items from the list". It's difficult to tell whether people are requesting these features for just the flyout, and/or the Special:Notifications page.

Regarding Bartosz's comment about filters, possibly bug 47093 is related.

Spage added a comment.Via ConduitSep 23 2013, 8:40 PM

Prioritization and scheduling of this bug is tracked on Mingle card

werdna removed a subscriber: werdna.Via WebDec 10 2014, 6:17 PM
Quiddity added a project: Collaboration-Team-Backlog.Via Bulk EditOct 28 2015, 1:31 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldOct 28 2015, 1:31 AM

Add Comment