https://bugzilla.wikimedia.org/show_bug.cgi?id=48481
Web browser: ---
Bug ID: 48481
Summary: Echo: "Mark all as read" also marks things not yet
seen
Product: MediaWiki extensions
Version: unspecified
Hardware: All
OS: All
Status: NEW
Keywords: code-update-regression, usability
Severity: normal
Priority: Unprioritized
Component: Echo
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected]
Classification: Unclassified
Mobile Platform: ---
A moment ago when I opened https://wikitech.wikimedia.org/ I had 11 unread
notifications.
It mentions " (showing 7/10)" on top.
After looking over the 7 messages quickly I want to see the other 3. There is
no pagination so I I click "Mark all as read". Now I have 0 unread
notifications. Where did the other 3 go? I haven't read those yet.
This happening suggests another bug existing (technical one as opposed to a
usability one). I suspect this is implemented by an API call that says "mark
all" (not just in the UI but in the API as well). Which means it is subject to
a logic error in race conditions. Events happening between me opening the
fly-out and me clicking "mark all as read" (or rather, the moment the server
processes that request), there can be new notifications.
Even if we'd have perfect real-time push notifications, this is unreliable. It
should probably add the ids of what it should mark to the API. e.g. like
ids[]=1&ids[]=2 or ids=1|2|3. See ApiPatrol and ApiQueryBase for similar
multi-value actions.
Marking as "usability", and also "code-update-regression" as I believe this
made the interface worse/dangerous for the user.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
