Track whether the user has read an in-site notification

[1ec5]

As with direct messages, we should track whether the user has read a given in-site notification. When listing notifications in the UI (#7018), the user would have an option to mark the notification as read (and perhaps unread). The API in #6896 should also indicate whether a given notification is read.

The total number of unread notifications can appear as a badge at the entry point for the list of notification. #3182 has some discussion about the potential design of this indicator. In the API, the current user details should indicate the total number of unread notifications. This would enable a client such as JOSM to display the number of unread notifications alongside the number of unread messages.

An alternative design for an unread count could rely on each notification’s timestamp and timestamp parameters on the notification list API call. JOSM would need to keep track of the last time notifications were checked. The downside of this approach is that the user would see a different number of unread notifications on each of the clients they use (across their desktop browser, phone, JOSM, etc.).

[tomhughes]

Well of course we're going to track it - the whole thing can't work without that so I'm not sure why you need to open an issue requesting something for a feature that isn't even merged yet and won't be merged without this.

[1ec5]

I marked this as a subissue of #1387. The current intention in #7030 is to land a list independently of a badge and an API – does this mean the single PR needs to include all the remaining notification-related functionality? There was a suggestion in #6896 that we could get away with relying on timestamps at first, but I’m not certain that would work due to mappers simultaneously using multiple clients.

[tomhughes]

Well I haven't reviewed that in any detail yet but I struggle to see how it can work without some way to track what has been read.

That's not saying you necessarily need a badge, but surely you need to be able to indicate which messages are new and which people have already read?

[1ec5]

As written, I think #7030 lists every notification the user has ever received since the feature was introduced. There’s pagination to avoid a super long page, but no option to filter it by date range or read status. #6896 proposes some API parameters for filtering the results by date range. I suppose #7030 could still be usable without individual read status as long as it tracks the last read date and draws a line above anything from that date. Discourse has a similar feature when listing watched threads with unread replies, and Slack and Discord have a similar feature when marking a message unread in a channel.

[pablobm]

Correct. My intention is have #7030 either not track read/seen at all, or to do the simplest thing possible (eg: a line separating items before/after the last time the list was opened). This is because I fear that this aspect of the interface can turn into a complex discussion and even more complex PR, all while this one is already marked as big-pr.

[tomhughes]

To be honest I was assuming the notification gem we're using would take care of recording which notifications had been read.

[pablobm]

The gem has the concept of seen/read, but how we use it is up to us.

[1ec5]

I marked #6896 as a blocker for this issue, but I think in principle we could implement an unread count independently of a fuller API. The main use case for API access to notifications is actually something like what JOSM has for direct messages: just a simple count of unread messages, which is part of the logged-in user details call, not the main messages portion of the API.

My intention is have #7030 either not track read/seen at all, or to do the simplest thing possible (eg: a line separating items before/after the last time the list was opened). This is because I fear that this aspect of the interface can turn into a complex discussion and even more complex PR, all while this one is already marked as big-pr.

It’s a tradeoff. The chat platforms that have a you’re-all-caught-up line also have an option to move that line. Marking a particular message unread makes all the subsequent messages unread.

If we implement this state as a timestamp, then it would need to be synchronized somehow across clients. Otherwise, if the user happens to visit their notifications on the website then open JOSM, JOSM will alert them to 18 unread notifications, but when they click through to the notification list, there aren’t any unread notifications.

On the other hand, if we implement this state by automatically flipping a read state on individual notifications, then we might need to consider race conditions and other edges. We wouldn’t want a newer notification to be read but an older notification to be unread, as that would complicate the list UI.

My gut feeling is that either individual read status or this timestamp-based approach would be involved enough that we’d want to split out a separate PR about it. The branch could be based on the existing branch for #7030.