we currently have in XWiki 3 switches at the top of the Notification area:
but I discovered while working on https://jira.xwiki.org/browse/XWIKI-17787 and https://jira.xwiki.org/browse/XWIKI-17799 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:
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).
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:
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.
We consider that watching a location should apply for all event types (except maybe Targetable Event types, see the related proposal: https://forum.xwiki.org/t/change-the-way-scopenotificationfilter-handle-targetable-events/7461/), so we modify Behaviour 2 to enable all event types instead of only Page Notifications ones if none is enabled.
We provide a configuration to allow admin to chose between solution 1 or solution 2.