Kallithea issues archive

Issue #181: notifications: spam: user receive their own notifications in the notification area

Reported by: Long Vu
State: new
Created on: 2015-12-18 19:22
Updated on: 2016-01-22 03:34


Kallithea 0.3

Mouse hover the top right corner where the user name is, user see "Notifications: ##". Click on that and user see the list of notifications, including his own notifs (create changeset comment, create pr comment, add new pr).

This is pure spam for the current user. The current user already know what he/she did.

The user is more interested in knowing what over activities happened since the last time he/she logged on.

I think there is still probably a good reason to show notif generated by the current user, in case the current user actually is a shared login but we should definitively have a way to filter/hide these self notifications.




Comment by Long Vu, on 2015-12-21 01:31

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

Comment by Long Vu, on 2015-12-21 01:34

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".

Comment by Mads Kiilerich, on 2015-12-22 13:01

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.

Comment by Søren Løvborg, on 2016-01-04 16:36

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.

Comment by Long Vu, on 2016-01-17 03:42

@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?

Comment by Mads Kiilerich, on 2016-01-17 15:00

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.

Comment by Søren Løvborg, on 2016-01-19 11:18

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.

Comment by Long Vu, on 2016-01-22 03:34

@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.