Page MenuHomePhabricator

Unread count in echo_unread_wikis cannot go back to zero
Closed, ResolvedPublic

Description

Regression from T124372 (https://gerrit.wikimedia.org/r/#/c/266235)

When alertCount is 0 and messageCount is 0 the line in echo_unread_wikis is neither updated nor deleted. See https://phabricator.wikimedia.org/diffusion/ECHO/browse/master/includes/UnreadWikis.php;2901417a580506c14077e1635bc1f4398db5857a$104

Removing that condition would help but we may not want the backfill script to create a 0,0 row for every single user.

Event Timeline

SBisson created this task.Feb 18 2016, 4:50 PM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptFeb 18 2016, 4:50 PM

If we don't want the 0,0 row, we'll probably need another table to keep track of whether or not users have ever had notifications (which we can now fetch from the timestamp associated with the 0,0 rows)
I thought it would be simplest to have those 0 rows (which consume very little storage) than keeping track of yet another thing in yet another place.

Or we could also consider not caring about hiding the "messages" icon for people who have never had a message before (on that wiki) and just display it anyway. It's the only thing we need those 0-rows for.

If we don't want the 0,0 row, we'll probably need another table to keep track of whether or not users have ever had notifications (which we can now fetch from the timestamp associated with the 0,0 rows)
I thought it would be simplest to have those 0 rows (which consume very little storage) than keeping track of yet another thing in yet another place.

We can have it and allow setting it back to 0,0 in UnreadWikis.php but we may not want to create all those 0,0 rows for every user in the backfill script.

Or we could also consider not caring about hiding the "messages" icon for people who have never had a message before (on that wiki) and just display it anyway. It's the only thing we need those 0-rows for.

That would be my preference but it's not my call.

Or we could also consider not caring about hiding the "messages" icon for people who have never had a message before (on that wiki) and just display it anyway. It's the only thing we need those 0-rows for.

+1

Hiding the message badge until the user receives it's first message ever (and showing always after even if the count is 0) seems a bit arbitrary. Wondering what the logic is, and if it's going to make sense when the meaning of the badges changes.

Always showing the badges would simplify the code. Such considerations shouldn't drive product decisions but since higher complexity means more bugs it's not to be ignored either.

/cc @jmatazzoni @Pginer-WMF

I don't have much background info about this, but I guess the idea was to keep things simple for those users not involved in conversations. That is, showing only two buckets for those that get involved in activities that require them.

There are some changes that may alleviate the potential problems due to this:

  • T115845: With the proposed design for badges, you no longer have a zero counter, just the de-emphasised icons, which make it less prominent.
  • T123018: If the notification types are redistributed among the different buckets, the group of users that only use one of them may be reduced.
  • Considering that exposing an empty panel may be common (especially for new users), we may want to provide better empty states. For example, not only telling the user that there are no notifications, but inviting them to get involved to start getting some. I recall we did something about the empty states, but I recall it was done under the assumption that it would be a very rare case. so we may need to revisit that.

Change 271603 had a related patch set uploaded (by Sbisson):
Allow setting the unread counts to 0 in the echo_unread_wikis

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

I don't have much background info about this, but I guess the idea was to keep things simple for those users not involved in conversations.

Yes, it was based on the limited deployment of Flow (don't show them a box with 0 that will never go positive).

Less of an issue now that we have edit-user-talk (non-Flow user talk), and as Pau said, will go away entirely when we change sorting scheme to urgent/non-urgent.

Change 271603 merged by jenkins-bot:
Allow setting the unread counts to 0 in the echo_unread_wikis

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

Change 271686 had a related patch set uploaded (by Catrope):
Allow setting the unread counts to 0 in the echo_unread_wikis

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

Change 271699 had a related patch set uploaded (by Catrope):
Allow setting the unread counts to 0 in the echo_unread_wikis

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

Change 271699 merged by jenkins-bot:
Allow setting the unread counts to 0 in the echo_unread_wikis

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

Change 271686 merged by jenkins-bot:
Allow setting the unread counts to 0 in the echo_unread_wikis

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

Checked in betalabs - foreign wiki notificaitons go to zero when they are Marked as read in their respective wikis.
Also, I checked the case when only foreign wiki notifications were present in the Notification panel. After foreign wiki notifications were Marked as read' - the Notification count goes to zero and the Notification panel displays 'There are no notification'.

jmatazzoni closed this task as Resolved.Feb 29 2016, 6:00 PM