I’m sorry to open this vote so late, so @ilie.andriuta discovered a regression (see XWIKI-21069) in the behaviour of Live Email Notifications related to my recent changes with the strategy for grouping notifications.
I will take an example to explain the change of behaviour: let’s assume that you have a grace time period of 1 minute and that you’re performing 4 editions of a page, 1 creation of another page, and 1 deletion of yet another page.
Before my change, after that minute, you will receive 3 emails: 1 for all the editions related to the page, 1 for the creation and 1 for the deletion.
After my change, after that minute, you will receive a single email containing all the 5 events.
But, after my change, you could change the default grouping email strategy, to decide receiving one email per event, to fallback on previous behaviour. But if you do that, it would apply not only for users having Live Email Notifications, but also for users having other kind of scheduling email notifications, including weekly mail notifications, which by default (and previous to my changes) are only sending a single email for users.
We should probably improve this in the future to allow having mail grouping strategies depending on the scheduling type (i.e. not same strategy for live and for weekly emails).
But the question is more about what to do for 15.5, as this behaviour has not been discussed yet and is already released as part of 15.5RC1.
There’s 2 options:
We keep it like that and we document the changes (i.e. we remove the mention “During this time, if events of the same kind are recieved, they will be grouped in the same email.” for the grace time period doc, and we mentioned the strategy instead)
I force using the strategy to send email per events for Live Email Notifications
For me 1. is probably a better solution because it’s more consistent, and it’s less dangerous than to change this 3 days before the release of 15.5.
I think 2 would be the right choice to leave us more time to think about the change. If the grace period was defined as it is now, it might be for a good reason that we don’t see ATM.
Apart from this, I also prefer the new strategy.
So +1 for 2, and -0 for 1.
EDIT: I wanted to move from -0 to +0 because the user can put back the old strategy. However, if you have 1000 users, I guess it’s a pain because even if you defined it in the admin UI, the setup is only a copy AFAIK and thus all 1000 users will need to change it. So I stayed with -0 in the end because of this.
ok thanks. Hmm I find it strange that it’s not the choice of the user though to decide if they want to receive one email or several… Possibly something to improve in the future.
I think changing the grouping strategy can really mess up email filtering. I’m +1 for 1 for the release of 15.5 as I think it’s really risky to change this now but overall I think it would be good if users could go back to the old variant and maybe we should even change the default back for live notifications.
We can go for 1 for 15.5 but we really need to implement the possibility to configure this per email type / channel.
To me it’s not a config that we need to show to users, we can definitely do it only behind the scenes as we already imply a grouping in the type of emails we propose, for this specific criteria of grouping:
digest, single email once an hour/day/week,
separate emails as soon as the events happen.
We need to be able to keep this promise so we need to be able to configure this in the platform. Showing to the user the possibility to choose to receive individual emails but all of them at once, once a week makes no sense, we have no reason to make an UI for that. We’ll need to make sure we don’t make the same “overconfiguration” mistakes that we already have in some notifications UIs.
Ok so closing this vote to proceed on 15.5 release. We have 4 +1 for option 1 and 1 +0 so I’m keeping current implementation. I will document the changes in the RN and open a new ticket for implementing the capability to chose the strategy per email notification scheduling.