Should we filter targetable event triggered by superadmin by default

Hi everyone,

right now by default we automatically filter out all events that are performed by the superadmin user so that the users doesn’t receive notifications related to the system. Of course it’s possible for a user to disable that filter, so they could receive those notifications, but it’s not the default behaviour.

Now, I’m wondering if we should keep this behaviour whenever the event is a TargetableEvent: such events are triggered to target specific people, either identified users or groups. When we use those TargetableEvent in general we do want the users to see them. However there is cases where it’s not easy to decide which context user to use for triggered those events, for example when those events are triggered from a scheduler.

The problem is that scheduler are executed with the user who created the scheduler page (in theory at least, see this ticket: [XWIKI-19765] Scheduler context author is always reset to guest when left empty - JIRA) but it’s possible that the page is created as part of an extension installed and that it’s been done with superadmin.

So my proposal would be that we skip the superadmin filter whenever the event is a TargetableEvent.

In general, I feel that we apply way too many filters for targetable events, at first pre-filtering was implemented to not take into account any filters for targetable events, but then all filters were applied to fix [XWIKI-17665] TargetableEvents are not discarded when Event type is switched off - JIRA.

So what do you suggest ?

Maybe we should go back to ignoring all filters and only do what XWIKI-17665 really was about: check if an event type is enabled or not for the user.

Well, if scheduler notifications is the source of your question from the title of this post, I think it’s a problem of authors of custom notifications triggered from a scheduler, not a problem of how to filter superadmin events.

To me it does not feel correct that a custom event that is triggered from a scheduler job takes as author the author of the scheduler job. This means that if I, user A, install an extension (and I am therefore author of the scheduler job page) and that scheduler job produces events upon its periodic execution, all those events will have myself as author and the filter “filter own events” would kick in and I wouldn’t receive any of it.

So the question is, actually: is the author of a scheduler job page the source of all the events periodically produced by that scheduler? I would say that no, it’s not necessarily true.

The scheduler jobs have a “context user” metadata, as far as I know, and using that context user as author of the events makes more sense. If that’s what all this discussion was about, excuse my nuisance, it just didn’t seem right that if I install an extension I might never receive notifications from its jobs because I am the author of the page…

So, by reading the tickets again, I guess this all boils down to extensions properly setting contextUsers metadata in the scheduler jobs they provide so that those jobs never use the “installer” user as author, but the “system user”.

yes, this feels right, to allow “the system” to talk to people on the wiki.

We just need to explain it properly on the UI and also be careful of the fact that while the system can talk to people, by default, own targeted events will still be filtered out (people cannot talk to themselves).

Maybe from an UI pov, 2 filters would make more sense here: system non-targeted events and system targeted events, same for own events, but that would be for a further version for the UI improvements.

So to be honest all that is a bit off topic: the scheduler is an example where notifications can be sent with superadmin.
Now you remarks are interesting for XWIKI-19765 so I’ll try to get back to them in the comments of the ticket.

So actually @mouhb pointed out to me that the current description of the system filter is actually:

Hide notifications from the System user unless the event specifically targets you

So it makes current behaviour a regression basically. I’ll create a ticket and go to @tmortagne solution:

A regression? As in it used to be different and it has changed? Or it’s only documented otherwise?

a bit hard to say as I don’t recall example of usages of targetable event in old versions of XWiki, and the notification has changed a lot with pre-filtering. So I think I’ll just consider it’s a regression since it was documented that way.