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.