Ignore the "Own Events" filter for targetted events

Development
,
#1

Currently, when the “Own Events” filter is enabled for a user (which is the default) that user never receive events for which the user is the source (for example when this user modified a document).

Problem is that this is true also for event which are explicitly targeting that same user, which IMO does not make much sense since if to make an effort to target this specific user it means it’s too important to be impacted by something like this. So I would like that we change the pre-filtering behavior to not take into account this filter in case of targeted events.

#2

+1
Thanks

#3

+1

Thanks,
Marius

#4

+1 Thanks

#5

Hello Thomas,

makes sense for the general concept of targeted events, but it may require to update the logic of some existing targeted events (such as mentions).

For example, I can find it hard to explain from a user experience point of view that if a user mentions themselves in a page (which may happen when the user is writing documentation in the 3rd person and not the 1st person, which is normal for a wiki), they would receive a notification that they mentioned themselves in a page.

However, from my pov, one important usecase of the targeted events is the implementation of ‘unrequested notifications’, when the system (the wiki) knows better what user should get notified of, without needing a preexisting subscription from that user. This is a valid usecase for some medium complex applications, especially involving workflow like features, and for this usecase indeed, filtering out the notifications for the user that ‘triggered’ the event is not OK, as you said.

So I would +0.9 this, provided that we address the potential user experience issue that it may raise for the mentions, as a fix of the mentions (and not of targeted events in general).

Thanks,
Anca

#6

All I can think of is to simply not produce an event when author=target, unless we would like to have an entry in the events core for each mention for other needs than notifying those targets. WDYT @mleduc ? Maybe it’s already what we do, I did not check ?

#7

Currently, we send the event even if the users mention themselves (it’s easy to filter out though).

#8

Hmm…
I think it may be a problem to be missing some events from the list of events only because they’re issued by the same user that is targeted…

Currently the mention events are handled as any other event by other usages of the events than the notifications (notably the event streams that can be displayed using the ‘notifications’ macro), see the usecase from this ticket [XWIKI-18698] Mentions are displayed in the event stream of a wiki as addressed to the current user when they're actually not - XWiki.org JIRA .
It’s a good question if a user mentioning themselves could be missing from this list of events:

  • from the point of view of users being mentioned, it is indeed just like any other mention, so it should be stored like any other mention
  • from the point of view of this event representing a social interaction of a user mentioning another user, it’s not a social interaction (a user mentioning themselves) so it could be skipped.

Knowing that these events could be used by some other feature, I really don’t know what to say about the risk of that being a problem.

Or maybe the initial UX issue is not such a big issue, maybe it is rare that users talk about themselves on the 3rd person and we should not complicate things for this usecase. I personally use mentions as a way to name a user, but not always to start a conversation with them (e.g. when I write meeting notes and I list the participants, I will probably use the @ mention in order to list all the people, because it’s easier, but I don’t have a need for a conversation there…)

@SilviaMacovei do you have any opinion about how mentions are (supposed to be) used?
and maybe about how frequent is the usage to name users from the wiki rather than have a conversation?

Sorry for making things complicated, @tmortagne . What’s sure is that it does makes sense to have the possibility to not filter targeted events to exclude own events, or at least to not have the default filter do that (maybe we can have a separate filter for own events for the targeted ones, to leave the choice…)

#9

Well actually I don’t agree with your example here. I can completely imagine using the mention feature for myself to get an actual notifications, not clear it and have a quick way to find back something I wanted to remember. If I disabled all other notif it might be a valid usecase.

That’s actually interesting, because for me the main UC for mention was actually the notifications: using it to ping user rather than to name them.

#10

Yes, for me too. To name users we have the {{useravatar}} macro.

#11

Of course, me too, most of the time. It’s not a main usecase for me to name users either (the main one remains the conversation), it’s just one usage.
In any case, it’s interesting feedback. The more I am thinking of it the more it looks like it’s actually not that big of a deal and we could send notifications for self-mentions without that being a major problem for the main usecase.

Interesting, I never used notifications that way, actually (like a tagged ‘note to self’). I have written “note to self”, in words, but I never tagged myself in any of them. So this is another ‘secondary’ usecase of mentions that needs to be taken into account, but it’s not the main one either.

Sure, it just doesn’t have a shortcut nor an equivalent in other tools.
My feedback from above about using mentions to name people comes from what I see that I do in other tools that support mentions. I must admit also that I didn’t search to see if there is an alternative to mentioning in other tools. I think expecting ‘normal’ users to do this (distinguish between useravatar and mention knowing that they would come with the @ habits from all other tools) would be too much.

But as I said above, I was probably wrong to worry so much about that, it’s not that much of an important usecase.
However, we’ll probably need to rename the filter “own events” in order to make it clear that it excludes targeted events or so, otherwise it would seem incoherent (making it hard for the users to understand what’s happening).

Thanks

#12

OK, thanks everyone. I applied the proposed change on own event and also on system event for the same reason (event created by superadmin are ignored by default, which does not make much sense in the case of a targetted event).

You mean the “Own Events Filter” name or only the description of that event (currently “Hide notifications about your own activity”) ? Feels like updating the description should probably be enough (especially don’t I don’t have a good idea for the name but maybe you do).

#13

Any is good as long as it’s mentioned somewhere, so that if a user really tries to understand what’s happening they have a chance of being able to. Description is probably the best, as it’s a complex thing to try to capture in a single ‘title’.