See also: T110731: Echo's 'seen time' should be replaced with marking specific notifications as seen
and
Related or duplicate? T139454: Notifications not updated across languages

Update from Leads Meeting 7/6/16
We had a long discussion about this in the leads meeting. Some salient points from that discussion:

• Everyone agrees that the "seen" status needs to be x-wiki.
• There was a long debate about whether it should be on a per-item, Boolean basis or based on a time-stamp.
• The Boolean option would ensure that items that had not actually been seen would not get marked as seen.
• The time stamp would mark all as "seen" that had occurred prior to the last time that the user checked notifications.
• Consensus Solution from the meeting was: Mark as seen globally based on the time when the user last checked the panel or the page. (Though this was not unanimous, and there was a feeling that perhaps we need to air the issue more fully.)
• But we believe we can wait until Roan returns to address this, as there are various issues we know he has opinions about.

Related to the discussion, I was asked to clarify the general behaviour for this:

• The purpose of the highlight (as well as the badge) is to indicate to the user what is new since the last time she checked the notifications.
• This highlighting is useful to focus the user attention on the area of most interest (the new stuff), but it is not essential to operate: new items are placed on top and the blue dot that marks them as unread tells already the user that they are pending of processing.
• Despite the internal names used in software or tickets (i.e., "seen") we are not aiming to keep track of whether the items are exposed to the user eyes or not. We don't need an extra layer of persistent state. Especially one that the user cannot control since it vanishes automatically in a second.
• I don't understand the case made for behaving differently. The notification panel contains 20 notifications but I can only see about 8 at a time (I need to scroll to see the rest in a relatively big monitor). So if I get more than 8 new notifications I'll miss the highlight of the notifications at the bottom of the panel (unless I scroll really really fast). But that does not seem a problem at all. I've already noticed that a lot of new notifications arrived and the blue dot on each of them will remind me they are pending of my attention until I read them (or mark them as read).
• What if I get 200 new notifications? Some notifications won't fit in the panel. As other notifications are removed, the next ones will appear at the bottom of the panel. Highlighting old notifications just because they appear makes the highlight harder to interpret (why is this old notification highlighted but not the one above it which is more recent?) and irrelevant in other cases (if I have not scrolled at the bottom of the panel, I won't see them becoming blue for a second).

I tried to describe this in other tickets (T110731#2417256) and meetings. Please let me know if anything is unclear and I'll try to provide more details.

Good summary Pau. Thanks!

@Pginer-WMF, you don't understand the case for behaving differently from *what*?

In T138569 I described why I see as the best way to use the different levels of warning to users:

I consider normal to have it read (at least for cross-wiki) when the button with the number of notifications turns grey; this means that I have opened the drop-down and I'm at least aware of the existence of the message - no need to make the button red again on each Wiki I visit. You can leave the entry in the drop-down list as unread (white background), even show a number >0 in the button, but it shouldn't turn red on each wiki, especially since it's no longer red on the home wiki.

If I get 200 notifications, I might consider opening up a ticket on the number of notifications :) One case where getting 200 notifications is valid is for a retired users which returns, but in that case, are notifications older than X months really relevant?

In T134855#2461448, @Strainu wrote:

@Pginer-WMF, you don't understand the case for behaving differently from *what*?

I was talking specifically about whether to highlight some of those 200 notifications as new (i.e., when the notification turns blue for a second and fades back to white) when they are added to the panel, since the panel only shows 20 at a time. My position is that the blue highlight should only happen when the notifications are really new, regardless of whether you have been exposed to them before or not.

Having 200 unread notifications is a legitimate scenario (although fortunately unfrequent according to our data), and our system marks all unread notifications with a blue dot so that you can process them, as well as allowing you to mark all as read and start from scratch.

This is really annoying, please fix it as fast as possible!

We discussed this in our team discussion meeting and @Mattflaschen-WMF came up with the following idea: when the user opens the cross-wiki bundle, update the seentimes of all wikis that appear in that bundle.

The other issues around seentime discussed on this task are not actually related to this bug, so they should be discussed somewhere else.

In T134855#2471979, @Catrope wrote:

We discussed this in our team discussion meeting and @Mattflaschen-WMF came up with the following idea: when the user opens the cross-wiki bundle, update the seentimes of all wikis that appear in that bundle.

Before merging this, we need to watch out for rECHO756948d48969: Allow requesting TS_ISO_8601 for ApiEchoMarkSeen, and deprecate TS_MW when dealing with cross-wiki between different versions of Echo.

The safe bet is to make sure the updated ApiEchoMarkSeen (which offers ISO 8601) is on all wikis before merging. Otherwise, old versions of Echo will ignore the timestampFormat parameter, which we're about to start using.

Change 301021 had a related patch set uploaded (by Mooeypoo):
[wip] Update and fetch seenTime per source

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

In T134855#2471979, @Catrope wrote:

We discussed this in our team discussion meeting and @Mattflaschen-WMF came up with the following idea: when the user opens the cross-wiki bundle, update the seentimes of all wikis that appear in that bundle.

The other issues around seentime discussed on this task are not actually related to this bug, so they should be discussed somewhere else.

The attached patch implements this strategy, but it doesn't fix everything. There are two more problems. Suppose I have seen all notifications everywhere, and then I receive a new notification on wiki A. If I first notice this on wiki B, then by opening the popup there I will update B's seentime and by expanding the cross-wiki bundle I will (with this patch) update A's seentime, and all is well.

However, if I first notice it on A (the wiki it came from) and view it there, A's seentime will be updated but B's won't. If I then visit B, I'll still see a highlighted badge because B's seentime is older than the most recent unread notification on A.

Moreover, seentime is not taken into account in the onOutputPageCheckLastModified, so a page with a highlighted badge can be cached in the user's browser.

The second problem should be easy to solve by considering the seentime in th CheckLastModified hook. As for the first problem, I think one way to solve that could be to make wiki A's seentime accessible to wiki B; this would probably mean we'd have to store seentimes using a global cache key with the wiki name in it (as opposed to a local cache key) if cross-wiki stuff is enabled.

However, if I first notice it on A (the wiki it came from) and view it there, A's seentime will be updated but B's won't. If I then visit B, I'll still see a highlighted badge because B's seentime is older than the most recent unread notification on A.

Can we highlight the badge if any source has a notification more recent than the source's seenTime?
sources.any { source.notifications.any { notification.timestamp > source.seenTime } }

Change 301021 merged by jenkins-bot:
Update and fetch seenTime per source

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

Change 304944 had a related patch set uploaded (by Catrope):
Take seentime into account in the CheckLastModified hook

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

In T134855#2497914, @Catrope wrote:

Moreover, seentime is not taken into account in the onOutputPageCheckLastModified, so a page with a highlighted badge can be cached in the user's browser.

[...] should be easy to solve by considering the seentime in th CheckLastModified hook.

Done in https://gerrit.wikimedia.org/r/304944

Change 304944 merged by jenkins-bot:
Take seentime into account in the CheckLastModified hook

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

Checked in betalabs

• • opening highlighted badges will make all notifications (any number from any numbers of wikis) 'seen'.
• if there are bundled local notifications or cross-wiki notificaitons, going to Special:Notificaitons page will highlight them
• the issue described in the ticket

to avoid highlighting a notifications from a different wiki if those have already been seen from any other wiki.

has not been addressed yet.

Change 308782 had a related patch set uploaded (by Mooeypoo):
Make seen/unseen badge more consistent across wikis

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

Change 308782 merged by jenkins-bot:
Make seen/unseen badge more consistent across wikis

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

When there are cross-wiki notifications, the badges will turn back to their active states (red/blue) upon page refreshing.

Change 310370 had a related patch set uploaded (by Mooeypoo):
Store global seenTime with global Ids rather than local IDs

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

Change 310460 had a related patch set uploaded (by Mooeypoo):
[wip] Convert 'seenTime' to a global property

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

I had a quick related conversation with @Mooeypoo about the highlight on the Notification Page:

The main purpose of the highlight is to explain why the notification badge was highlighted in blue/red. The colored badge is telling you there are new notifications, and the highlight shown when opening it will help you identify how many new ones you got (something you can do in any case thanks to the chronological order).

For the Notification page the highlight is less important. While it is ok to do the highlighting when you get there, for cases where determining the "seen time" is hard (e.g., because alerts but not notices panel was opened) it is totally fine to be conservative and not show the highlight (as opposed to highlight alternate rows in the list). Having no highlight at all in the Notification page won't be also a big problem.

Change 310698 had a related patch set uploaded (by Mooeypoo):
Update the badges' seen state when Special:Notifications is visited

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

@Mooeypoo, which of the following explanations is the right one?

Notifications from a different wiki, if those have already been seen from any other wiki, will not be highlighted until they are marked as read for good.

Notifications from a different wiki, if those have already been seen from any other wiki, will turn the notification badge black until they are marked as read for good.

Discussed with Moriel. The right one is
"On Notifications, the badge is colored if you have some notifications. If you click on the badge it turns grey on the wiki where you are. In the future, it will turn grey on all wikis".

Change 310370 abandoned by Mooeypoo:
Store global seenTime with global Ids rather than local IDs

Reason:
Changing the entire behavior in another commit to make seen time global

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

Change 310698 merged by jenkins-bot:
Update the badges' seen state when Special:Notifications is visited

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

Checked in betalabs - works exactly according to the description in https://gerrit.wikimedia.org/r/310698 (cheked for cross-wiki notificaitons too):

Update the badges' seen state when Special:Notifications is visited

When the special page is loaded, all notifications should be marked
as seen for both the no-js and JS versions.

Change 310460 merged by jenkins-bot:
Convert 'seenTime' to a global property

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

Checked in betalabs the following steps

• a user has new notifications in wiki A (red or blue badge color is displayed)
• the user logs to wiki A and open the Notification panel or goes to Special:Notifications

Result: the notificaitons are marked as seen (the badges are grey)

• the user goes to wiki B and sees the same grey color badges indicating that the user already saw the notifications in wiki A

Also, checked for cases when there are only cross-wiki notificaitons bundles; and when the user only visits Special:Notifications page without opening the notification panel.