Kallithea issues archive

Proof-of-concept patch, hardcode the hiding of current user works but pagination does not work.

Any suggestions on what is the good/prefered way to make this configurable?

I want to avoid the case where I spend more time on this, then it turns out "it is not the way it should have been done".

Hmm ... yeah ...

I think shared logins is a bad idea and not a use case we have to consider. I think we can call it a bug that users own notifications show up in the notification list.

786640c577f3 touched upon this and @kwi can perhaps comment more on it.

Instead of just fixing the display of notifications as in your proposed patch, I think we just should skip creating the notification instead of marking it read.

This behavior has changed since v0.3. In the current development version of Kallithea, notifications generated by the user remain visible (in the actual notification list), but are automatically marked read. In other words, they do not show up in the top-right corner. (With the suggested patch, it's the reverse...)

I favored this approach over completely removing them, because the list of notifications form a chronological log or audit trail of events, and I figured it'd be confusing if entries were missing from that list. But as of 786640c577f3, they do not show up as unread.

I'm thus tempted to say that the issue has been solved, unless you think that automatically marking as read is insufficient.

@kwi I think marking read is still insufficient.

Consider the case where user got notif (not from himself), do not read those notif immediately and continue to do more work (create PR, review ...). By the time user get to the notif area, all the unread from other users are many pages later and he has to scroll and scroll until he reaches them (because his own notif are displayed first because they are latest).

I have no objection with keeping our own notif and marking them read right away but we need a way to hide them to avoid distraction and excessive scrolling.

Ideally we should also be able to filter by user and/or by repo. If there are 100 users and 100 repos on the system but I only collaborate with 2 others, ideally I'd like to only see notif from these 2 other users and only in the repos that I work with them.

How are you guys making use of this notification area?

No, we don't really use the notifications much - we mainly use mail notficiations. Some try to use them, though. That confirms that big changes are needed. It might be possible to make minor improvements to the existing system, but it seems like it needs to be redesigned considering relevant use cases.

The argument about the clutter of already read notifications hiding the unread ones is relevant, but applies independently of the sender of those notifications.

Seems a good solution would be to hide read notifications by default. (Like GitHub, come to think of it.)

That should be rather simple to implement, in the same vein as the filtering by notification type.

@kwi I like the idea of "hide read notifications" by default but still allow the user to show them if they wish.

I'd submit a PR when I have some spare cycles.