Notification Filter Preferences storage location

Hello all,

I came across the notification filter preferences storage to fix a few bugs, and noticed a bunch of issues.

To summarize what I understood of the intent of the existing code, two properties exists:

  • eventstream.uselocalstore (default to true): indicates that the notification filter preferences should be stored in the local wiki
  • eventstream.usemainstore (default to true): indicates that the notifications filter preference should be stored in the main wiki

Some issues I have noted:

  • I hard a time linking the properties name to the module where they are used (probably for legacy reasons)
  • both properties can be true at the same time (or false), meaning that both can be deactivated and the filter preferences are not stored, or that both can be activated at the same time and the notification filter preferences are duplicated
  • currently, when the local store is used, the choice of the wiki is made by using the wiki in context and not the wiki of the owner of the filter preferences (meaning that watching a user from a subwiki with a user from the main wiki will store the corresponding filter preference in said subwiki, instead of the main wiki, making it “lost”)
  • these properties are not used consistently, some part of the code use both to determine where to store the filter preferences (e.g., DocumentMovedListener), and some other parts only rely on eventstream.usemainstore

In summary, those configuration offers too much flexibility, and allows for inconsistent configuration.

Below some options of

Option 1: main wiki only

In this case we need to deprecate the properties, and to copy the filter preferences from the subwiki to the main wiki.

Option 2: local only

By local, I mean to always store the filter preferences in the wiki of their owner.

In this case we need to deprecate the properties, and to re-dispatch the filter preferences from the main wiki to their right wiki.

Option 3: configurable

Introduction a new property usemainstore.
When usemainstore apply option 1, when usemainstore is false apply option 2.

Note that regardless of the option, some listener are required in order to cleanup filter preferences in case of:

  • deleted wiki
  • deleted user
  • deleted page
  • deleted space

I’d vote +1 for option 2, +0 for option 1, and -1 for option 3 unless somebody has a good motivation for it (I failed to find some advantages of this flexibility).

WDYT?

It’s not really clear what you mean by “local” in your options.

For me, the user preferences should be stored in the user wiki.

Exactly, I’ve updated the first post with:

By local, I mean to always store the filter preferences in the wiki of their owner.

I guess this is not needed most of the time since it was already the case by default from what I understood of your first message.

The current default is to have everything on the main wiki only, expected for DocumentMovedListener which consider both.

That’s not what I understood from

edit: ha it’s because of

?

Yes, that’s what the documentation says (and what I think was initially planned), but not what is implemented in practice.

Anyway, I was not suggesting to not do any migration since it’s technically possible. Was just mentioning that it seems OK in most cases, so the migration would probably not have much to do.