Do we want to do this server- or clientside?

In T129364#2144445, @matthiasmullie wrote:

Do we want to do this server- or clientside?

I think we'd want to do this on the server side, but we already have it there in the API module, don't we?

Yeah, the filtering should definitely be done on the backend.
I meant: will this be a JS feature (where it'll call the api to get filtered results), or do we also want these filters to work without JS

I've think about that need of server server versus user side and I haven't identify possible users needs to save the current filters. So user side is fine.

I haven't identify possible users needs to save the current filters

Making the URL aware of the filters (i.e., making them bookmarkable) provides flexibility for users to keep specific views (e.g., quick access to unread messages on user talk page) and usually helps to keep the status when navigating out of the page and back again. I'm not sure this falls under the concept of "save" that @Trizek-WMF mentioned, or whether this has an influence of the client/server decision (since the above can probably be supported with both models).

I've considered filtering read/unread/all messages only, based on a simple JavaScript request (so without any visible URL). I haven't seen that approach, Pau.

Complex queries like having first all notifications from English WIkiVoyage and Arabic Wiktionary would be really useful if visible on the URL ("hey, Cronopio, how do you manage to see all Flow messages from Urdu Wikiquote?"). And finally, so as read/unread.

In T129364#2147680, @matthiasmullie wrote:

Yeah, the filtering should definitely be done on the backend.
I meant: will this be a JS feature (where it'll call the api to get filtered results), or do we also want these filters to work without JS

We agreed that the no-JS version of the special page would be fairly minimal, so we don't necessarily have to have these filters work on the special page. That said, it probably wouldn't be much work.

I thought he said that showing Read messages from all foreign wikis would be hard.

We know (by querying a single table) exactly which wikis they have unread messages at (typically, a small fraction of our 800+ wikis), and exactly how many they have at each.

We don't know either of those things for read messages without querying each database separately, which would probably be impractical (without a schema change).

I thought he said that showing Read messages from all foreign wikis would be hard.

Ach. Yes, I meant Read. I'm going to correct my previous message and repost it below.

[I when I first posted the comment below, I very confusingly said "Unread" when I meant to say "Read." I deleted the old version; here is the corrected comment.]

At one point Roan mentioned that getting Read msgs from foreign wikis is hard. So I have some questions about Read msgs from foreign wikis:

1. With All Contents selected, the user clicks Read: does she see Read messages from all the wikis she participates in? The same question applies if the user clicks All Contents and All, actually.

2. How far back do those Read msgs go? All the way to the 2000-msg. limit for all wikis? So, potentially, tens of thousands of msgs, depending on how many wikis the user participates in?

Here's a different scenario:

3. While filtering by Read, the user marks a message as Unread. Does the message disappear from the message list? I'd say yes. (And the same for the reverse scenario; i.e., when the user is filtering by Unread.)

I was working under the assumption that getting unread notifications from different wikis into a single list was the hard part.

This is the reason why I simplified the designs to avoid aggregated lists (e.g., all notifications related to all my watchlisted pages from different wikis). Instead, the designs assume that you have always a specific wiki selected (more details in T129366). Surfacing the number of unread notifications on each wiki in the sidebar acts as the glue to keep the experience still perceived as "global".

This means that for this specific ticket, read/unread filter will affect the current selected wiki, which will be the local wiki until we provide means to select a different one. In any case, they will filter content for no more than one wiki.

Pau has created a new design that simplifies some of the issues referenced above considerably, The new design, shown below, avoids the problems associated with retrieving Read X-wiki notifications--by removing the features that aggregated X-wiki results. The user can still view notifications from other wikis and can filter by Read/Unread, but he can view items from only one wiki at at a time. Here is that new concept:

So,regarding my questions from above:

1. With All Contents selected, the user clicks Read: does she see Read messages from all the wikis she participates in? ...
2. How far back do those Read msgs go? All the way to the 2000-msg. limit for all wikis? So, potentially, tens of thousands of msgs, depending on how many wikis the user participates in?

The answers are now easy:

1. This issue has been eliminated. Disregard the question.
2. Yes, when filtering by All or Read, the user cah page back to the end of the available notification queue -- which is limited at 2000. However, the idea of potentially being able to view many thousands of messages is now off the table.

Thanks for an elegant solution @Pginer-WMF!

My question #3, about the interaction of Mark as Read/Unread and the Read/Unread filters still applies. And the answer still seems to me to be that if a notification, having had its Read/Unread state changed, is no longer consistent with the current Read/Unread filter status, it should cease to be displayed.

My question #3, about the interaction of Mark as Read/Unread and the Read/Unread filters still applies. And the answer still seems to me to be that if a notification, having had its Read/Unread state changed, is no longer consistent with the current Read/Unread filter status, it should cease to be displayed.

Your interpretation is correct according to the designs. We may want to provide a transition to better communicate visually when items disappear from the filtered views.

Done in rECHOe5e19dd0f1fd: Filter notifications by read state in Special:Notifications

Special:Notifications page currently has 'All', 'Read', and 'Unread' filters (no cross-wiki). The functionality was checked as part of other tickets verification process.

Please let me know if #1 and #2 require additional tickets to be filed.

Below I listed what specs from this ticket have not been implemented:

Status views should be bookmarkable. That is, the current view >should reflect in the URL so that users can keep links and bookmarks >directly to it.

2. Pages with no notifications - T113070: Display a 'no notifications' empty option if there are no notifications in the Echo popup

If there are notifications but all of them are read, the "unread" >view will show an empty state with an action to reset the filters >(going to the "all" view) as the suggested next step.

If there are notifications but all of them are unread, the "read" view will show an empty state with an action to reset the filters >(going to the "all" view) as the suggested next step

3. Providing a convenient way for a user to review filtered messages for certain dates

When switching views context is kept based on the date groups. If the user is not on the first page...

Please let me know if #1 and #2 require additional tickets to be filed.

Thanks @Etonkovidova. The answers are:

• 1) that's not easy at this point because of some back-end stuff that needs to be fixed. But we want to do it. So yes, please file a separate ticket and tag it for Collab-Team-Interested, Near Term.
• 2) Moriel says this will not take her long at all, so I'm bouncing back to RFP for her to pick up and finish.

@jmatazzoni
I think this task can be closed - all three specs that were listed as not implemented can be addressed in different tickets.

1. Bookmarking is hard to implement at the present.
2. T113070: Display a 'no notifications' empty option if there are no notifications in the Echo popup is split up from this ticket and presently in Collaboration-Team-Interested(Freezer)
3. Switching view context based on the user selected date filter - may need more research/discussion? Or it can also be split up into a different ticket.

I think this task can be closed - all three specs that were listed as not implemented can be addressed in different tickets.

I created a separate tickets for the pending issues:

• T137862: Make Notification page filters bookmarkable
• T137863: Keep pagination consistent when switching status filters on the Notification Page