this is yet another proposal related to notifications. I’d like to propose another technical behavioural change related to how events are grouped by default to form composite events, and then to be displayed.
Right now the default algorithm for grouping events is based on 3 criteria:
- the type of the events
- the document involved in the event
- the groupId of the event
The two first criteria are not difficult to understand: we group events that are of similar type and targeting same document basically. The third one is more complicated, and that’s the one I’d like to get rid of: right now we might group recordable events that are not of the same type, if they have been triggered during the same activity.
For me this is the hack for hiding the fact that we are wrongly triggering technical recordable events not related to the actual activity we’re doing.
For example, if you’re adding an annotation to a document, right now 3 recordable events (aka notifications events) are triggered:
- first, the update recordable event
- second, a comment recordable event (because annotation are stored as comment)
- third, an annotation recordable event
Right now, the default algorithm consists in grouping those 3 events, even if their type is unrelated. Worst thing is that since we’re mixing unrelated events in the CompositeEvent class, we also need a hack for checking the type to take the latest type and ignore the “update”/“create” technical types (see: CompositeEvent. Also it complexify the code for grouping the events, see the dedicated condition.
And finally we also need to handle this at template levels, since else we’d show all events in the details even the unrelated ones, see the macro we have
So my proposal would be to:
- Remove all those hacks and condition, so the default grouping algorithm would be only based on type and document
- Improve our listeners in XS to only trigger the RecordableEvents when the activity related to the event is done: i.e. don’t trigger an update recordable, if it’s for an actual comment or annotation, by checking in the listener the context of the event, and probably by creating some dedicated folded events
The pro of my proposal is that it would simplify a lot maintaining notifications as we’ll stop having weird exceptions, and it also simplify writing/customizing templates.
The cons is that there will be a change in behaviour that will impact extensions: I expect that some extensions do rely on that behaviour for their notifications, because they don’t use folded events and they update pages.
It’s a big cons, I don’t have a magical solution for it, except reviewing extension that uses custom notifications (AFAIR, there’s not that many), so we could even start by doing that.