This is actually a difficult feature to implement due to potential performance issues. If a user has thousands of unread notifications (which is possible) updating them all at once would be an expensive hit on the database. In those cases we may want to defer the job to the job queue or do some sort of batching.

Yes, based on our recent discussion, this would have to be postponed to a later date, since it doesn't seem practical for our first release next week. So I have lowered the priority, to give us time to explore back-end implementation strategies.

Related URL: https://gerrit.wikimedia.org/r/59568 (Gerrit Change Ifcb0a436e2b31062741c441cca239d35ddefa0e1)

I checked in an initial version without performance safeguards as change Ifcb0a436. Marked as -2 for now.

Added some limitations for performance reasons and deployed. Still need a solution for users with thousands of unread notifications (right now they just have to clear them all manually).

Related URL: https://gerrit.wikimedia.org/r/64858 (Gerrit Change I7896abbc1b8268d13692a0521b7c696226618b76)

Checked in an initial implemention of batch updating the user notifications using the same components we use in db migrations. Echo already contains an appropriate index for the query( the user_event index on echo_notification ) but there may be other concerns i'm not aware of.

I get a "mark all as read" button on my flyout (added in Ifcb0a436e2b31062741c441cca239d35ddefa0e1), but not on [[Special:Notifications]] itself. Is that still being worked on?

Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/201

Change 64858 abandoned by EBernhardson:
Batch update job for unread user notifications

Reason:
there wasn't really much interest

https://gerrit.wikimedia.org/r/64858