[openstreetmap/openstreetmap-website] Track whether the user has read an in-site notification (Issue #7123)

[Minh Nguyễn]

1ec5 left a comment (openstreetmap/openstreetmap-website#7123)

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](https://wiki.openstreetmap.org/wiki/API_v0.6#Details_of_the_logged-in_user:_GET_/api/0.6/user/details) call, not the main messages portion of the API.

> My intention is have https://github.com/openstreetmap/openstreetmap-website/pull/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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/7123#issuecomment-4624077722
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/7123/4624077722 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260604/6a65da26/attachment.htm>