Clarify the behaviour of Notification watch switches

Hi everyone,

we currently have in XWiki 3 switches at the top of the Notification area:
notification-switches but I discovered while working on and that their behaviour was far from being obvious. And on the contrary I now think it’s too ambiguous to be properly used since it could cause unexpected behaviour for the end user.

So right now manipulating those switches will call the watch/unwatch script service API on a specified location. But those APIs are now doing two things:

  1. they create a filter to be used in ScopeNotificationFilter, the filter is inclusive for watch, exclusive for unwatch, it concerns all event types and it’s about the chosen location (current page/space/wiki).

  2. if no notifications preferences for at least one of the type “create/update/delete/addComment” (I will call them Pages Notifications, since they appear in the UI like that) is enabled, it enables the notifications preferences for all those types on both formats alert and emails.

The first behaviour is expected since it’s exactly what’s about watching a location means for XWiki: it’s having the right notifications filter for this location.
Now the second behaviour is more problematic: it has been created in order to allow auto-watching a page, basically when you create a page and you haven’t enabled any notifications yet then a location filter is created on that page (behaviour 1) and then the Pages notifications are enabled to be sure the user will receive notifications about the page just created. We even have the following comment in the code for this behaviour:

// If the notifications for the XWiki app (create, update, delete, addComment) are not enabled but autowatch
// is on, then we need to enable the notifications in the user preferences.
 // We do that because it has no sense for a user to use the "AutoWatch" feature when the notifications are
// not enabled.
// Moreover, it makes the notifications feature discoverable. It means that, by default, all pages where the
// user has made a contribution will generate notifications. That's probably what users expect from a
// notification area.

The problem is that, as I specified behaviour 1 concerns all events types, while behaviour 2 concerns only Page Notifications. So if for example you install the Blog Extension, you enable Blog Notifications and you want to watch a space (for receiving Blog Notifications), you will in fact also enable the Pages Notifications automatically without noticing it.
So we are not explicit enough about what type of events exactly those switches should act on, and I propose that we change that.

I see currently 3 solutions:

  1. We force those switches to only act on Page Notifications, it means changing behaviour 1 to create only filters for create/update/delete/addComment event types. Doing that also mean that those switches should never been able if the Pages notifications are not enabled (right now they are enabled if any Notification type is enabled). In order to avoid a UI regression we could still display them as enabled if a filter is created for all event types on a specific space I guess.

  2. We consider that watching a location should apply for all event types (except maybe Targetable Event types, see the related proposal:, so we modify Behaviour 2 to enable all event types instead of only Page Notifications ones if none is enabled.

  3. We provide a configuration to allow admin to chose between solution 1 or solution 2.


For me the most logical is solution 2, i.e. consider that the watch toggles apply to all notification types and they simply create a filter based on the location.


So solution 2 is not exactly what you suggest, we already create a filter only based on the location. See:

So what you’re mentioning is actually the first behaviour that we already do. Now the question is about the second behaviour, from your answer I can imagine two things:

  • either you agree with my proposal 2 which was:
  • or you want that we completely discard this second behaviour: meaning that if no notification type is enabled, the filter would be created but would be useless until the user enabled one notification type.

hmm I don’t get it. You proposed this solution2:

I agree with this. How is that not " i.e. consider that the watch toggles apply to all notification types and they simply create a filter based on the location."?

In any case your solution seems the best to me: the toggles apply to all notif types.

Maybe it is but the sentence is ambiguous:

they simply create a filter based on the location

If you’re saying we only need to do this, then it’s wrong. It’s not sufficient, even if you imply that the filter will act on all event types.
We need to do that (actually we already do) AND to enable all event types in Notification Preferences instead of only Page Notifications: here it’s not a filter in the Notification vocabulary.

Ok then yes we agree. I didn’t mean that it was enough to do just that.

1 Like

Hi, pointed here from Matrix by @surli, IMHO we could first clarify the meaning of the various settings, notably make explicit that:

  • the triggering events will be computed from the intersection of application/event type and location filters (“what if a location filter enables an event type that was not enabled in app/event types filters?”)
  • System events are default, non-app-related pages (“a blog post being a page, should I also enable page events beyond Blog events?”)
  • admin settings are default settings applied to users not having interacted with the personal notification settings nor contributed any content (in autowatch) (“are all users affected by my changes as wiki admin?”)
  • when a user will explictly or implicitly (through a contribution) watch something, his personal app/event type filters will be enabled (the current topic) so there is no need for the wiki admin to switch on the System type event
  • … given that enabling an app/event type currently notifies new users about all events from the whole farm, displays all 3 watch toggles as “on” on all pages, and that one can’t explictly watch a specific page or space without unintendedly excluding the wiki in the first place.

Then, I think the cohabitation of Blog and System (standard page) as same-level event type filters is also a source of the confusion this topic addresses. Am I supposed to subscribe to a blog by watchnig the blog space, or by switching on the blogpost publication event type in my notifications profile (which lacks the individual blog names, btw)?

If I correctly understand that post publication is a fully distinct event from a page creation, it could be clearer to have a “subscribe” button/link on the blog page (wich would enable the appropriate filter) and to dedicate the toggle triplet of the notification drawer to standard page events only. Thus you wouldn’t need to make assumptions on the types to implicitly enable when a first page is watched.

Furthermore, because of the everything-notified & exclude-wiki problem when page notification types are enabled without any location filter, I suggest not using the location-dependent toggles to reflect an implicit behavior induced by the global event type filters. It could be clearer to have a distinct setting for being notified of all or no wiki events as long as a user has no explicit watch set.

Hello Simon,

so, this is awfully complicated, for a single reason: that the System events are de-activated by default and whenever someone watches something we need to actually activate them so that that watch actually makes sense.

Now, the only reason I find for those events to be deactivated by default - which is very counter intuitive - is because by default not watching anything means watching everything, and I guess we want to avoid spamming.This has at least 2 other unexpected effects:

  • all watch switches appear turned on everywhere, so the user cannot subscribe to anything, yet they don’t receive any notification
  • if autowatch is enabled (and it is, by default), strange things will happen when they will modify their first page - for example, if they activated the events and they were receiving notifications for the whole wiki, that will stop (they will only receive events for the page they modified). If they haven’t, they will at least stop seeing all switches on (they’ll magically go off and they’ll need to turn them on).

So it appears that we’re trying to achieve an opt-in for notifications but starting with a default of opt-out and hacking it to stop it. Also, it appears that we’re focusing the management of notifications on the event types (and making an assumption about location), when, I think, it would be easier to focus it on locations (and make an assumption that all events are interesting).

So, I would say we should just drop this magical enabling of things upon watch (neither solution 1 nor solution 2 from your proposal, @surli ) and go back to a simpler solution for the opt-in that we seem to be targeting (let’s call this “Solution 3”):

  • all event types are enabled by default - at global level
  • no filter means no notifications at all : not watching anything means not watching anything
  • when a user watches a location - manually or automatically - they will start receiving whatever event types they have configured in their profile (or inherit from global level).
    • if we want to avoid confusion of the user here (which may wonder why they don’t receive any notification when all events are enabled), maybe we can display, in their profile, a warning that they haven’t yet subscribed to any location and they should use the switch in the bell menu to do so.

So, to me, none of the 2 solutions you proposed, @surli, does the job because they’re actually overwriting the user’s settings, as far as I understand, which can be difficultly defended as a reasonable thing to do. To me, this overwrite only makes sense when the user’s settings are the default ones (once the user has made a setting in their profile, overwriting that setting is completely wrong). IMO, we only made this choice (of overwriting), because the default is incomprehensible. So I would say the solution is to have a default that is more comprehensible, and never overwrite those settings (which is Solution 3 above).

I think there are issues open for a bunch of this incomprehensible behaviour (e.g. but probably more). I would probably also rollback the fix for , I think I prefer to see the switch as on, if there is at least one event that I’m watching for that location. With the new default it would make more sense…

I think all this would imply a rather good amount of breaking changes in terms of default behaviour, but I personally can hardly imagine anyone relying on this default, it’s so so messy.

Question A:
I personally don’t see anything that is part of the default behaviour now and that Solution 3 would change in a bad way. Can anyone think of such a case?

Question B:

  • no filter means no notifications at all : not watching anything means not watching anything

Maybe we can make this part of Solution 3 configurable, and allow to configure this in a configuration in or so, to allow someone to setup a spamming wiki by default (a fully opt-out), if they wish to. But then again, we have global filters now, so having such a spammy wiki is really not hard now for an admin. WDYT?

It would be interesting to dig the sources of these decisions…

Just to align vocabulary, I guess what you’re calling “System events” here is what I called “Page Notifications” in my first message:

IMO it makes sense with the strategy you propose for the default event types (create/update/delete/addComment) and even the one provided by bundled extension in XS (like and mention, which is actually already enabled by default).
Now I’m not so sure it would be right to enable notifications globally for events provided by a new extension you just installed. Maybe that could be a value to declare when you provide a new event descriptor: to specify what should be its default setting (enabled or not).

My recollection about using an opt-in for the watch was that we were enabling the notifications so that users would discover the feature by having notifications automatically when some activity starts to happen on the wiki. I’m now not sure it’s needed, but we need to remind that currently the only location where you can decide to watch/unwatch a page easily (aka without creating a complicated filter and just by pressing switches) is through the notification area. IMO it’s unlikely users would discover that location by mistake, so I think that if we want to go in the direction you propose we should also provide a better discoverability of that feature. Maybe a way for doing that would be to specify in the page information tab if the page is watched or not, and allow to modify it here too.

I guess what you’re calling “System events” here is what I called “Page Notifications”

Indeed, sorry for that.

Probably, but it’s not currently the case by default in the wiki.
Currently, the first user of a wiki (e.g. admin when running the demo distribution) watches all the pages (because they watch nothing) but doesn’t receive any notifications because the Page Notifications are disabled in the “Applications” section (btw, didn’t we say we’d call that “event types”?).
So it’s discoverable but not really, the administrator still needs enable notifications on the wiki, and they would do that by going to the global notification administration and configure the event types to enable page notifications. So it still requires an action from this first user running the demo distribution in order to make the feature discoverable.
This is what I meant in my previous message when I said that we seem to be focusing management on event types when we should focus them on locations.
And this is also what I meant that we’re doing opt-in by starting with an opt-out and then hacking it.

Now, this way of doing things was probably also limited by the absence of the global filters, today (after XWIKI-18406) it would be simpler to allow the admin to enable notifications everywhere (to make users discover them) even if the default would be that they watch nothing: the admin would just need add a global inclusive filter for the whole wiki and notifications would be pushed to all users. Thus, we don’t really have a reason, from my pov, to keep the behaviour of “not watching anything means watching everything”.

One more argument against this behaviour is the fact that once the administrator activates the event types in the global administration, all users receive notifications for all locations on the wiki (including, for example, the XWiki space). The fact that users receive notifications for the XWiki can be a problem, and in the past the absence of global filters made it impossible for an administrator to fix it otherwise than by deactivating all notifications or running a script to update the notification preferences of all users.

What would be wrong in enabling the new event types globally? That users that are not interested in those events would receive them.
My take on this is the following: since the admin is the one that is installing the application, I wouldn’t put this situation in the “side-effect” category (a user doing something that is wrongfully impacting another user). The admin is a special user who should be concerned by the wellbeing of the users when doing actions on the wiki and if the admin worries about the events, they can go to the administration and disable that specific event type globally (would this work?).
Also, if we consider that the focus of the user is locations and they need to manifest that interest by watching some locations, we can consider that as an implicit agreement to notify about whatever happens in those locations (current and future event types). Of course, they can then opt-out if it turns out that the locations are interesting but not that specific event.

Yes this would work.

So just to be a bit more precise: we should not forget that some notifications are not about locations: they can target directly groups or users, some for some event types the location watch is not used at all. But I admit it’s rare, and in general when events targets people it means you really want them to receive the notifications.

So all in all, I think I agree with you that your strategy would be better. My only concern now is about the backward compatibility of such behaviour change: I don’t think it would be really a problem for upgrades since it won’t impact users having already specific settings, now it could be surprising for administrators that have habits using old version of XWiki.
Maybe we can handle that with a specific property to allow fallback on the old mode, when we’ll change it.

Yeah, I know about that, but to me this kind of notif is for a usecase that I call “the system knows better” - which means that the wiki will determine that this event is interesting for this user beyond what the user has expressed (which is why targeted events are not restricted to followed locations), and in that case you probably really want them to receive the notif.

Yeah, it’s true that it has backwards compat impact which in principle is a bad thing, but as I said above, if anyone is relying on those defaults it means they understand them which means someone has managed to find meaning in chaos. I want to meet those people, let’s break the compatibility so that they come complain on the forum so that I meet them and express my admiration :slightly_smiling_face: .