Page MenuHomePhabricator

Can't hide items on Special:Notifications
Closed, ResolvedPublic


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.

See Also:



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:28 AM
bzimport added a project: Notifications.
bzimport set Reference to bz46692.
bzimport added a subscriber: Unknown Object (MLST).

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.

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

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

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.

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.

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

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?

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.

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.

Prioritization and scheduling of this bug is tracked on Mingle card

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 28 2015, 1:31 AM
matej_suchanek removed a subscriber: wikibugs-l-list.
Petar.petkovic closed this task as Resolved.Jan 11 2018, 5:27 PM
Petar.petkovic claimed this task.
Petar.petkovic added a subscriber: Petar.petkovic.

Ability to mark notification as read is now available. Closing the ticket.