XWIKI-18998: Replace the Livetable of the System Filters of the Notifications Administration with a Live Data macro

[manuelleduc]

Jira URL

https://jira.xwiki.org/browse/XWIKI-18998

Changes

Description

• Replace the System Filters Live Table with a Live Data

Bonus: better handling of the toggles on error

Clarifications

• Introduction of a DisplayerToggle Vue component for the display of the togglers in the new xwiki-platform-notifications-webjar (second webjar + npm module after xwiki-platform-livedata-webjar).
  • Based on Vite instead of webpack in preparation for the migration to Vue 3
  • Simple project structure with everything inside src/main/vue instead having the config in a separate place, making the code and the build more difficult to understand
  • xwiki-platform-livedata-webjar now exposes displayerMixin, BaseDisplayer, XWikiIcon, and XWikiLivedata (instead of XWikiLivedata) because they are required by DisplayerToggle)
• All the Livetable hacking logic replaced by a listener to the toggles events (maybe @surli to validate that I did not remove too much).
• Introduction of an internal emit even on XWikiIcon, so that DisplayerToggle can know when the component is initialized.

Screenshots & Video

Before

After

Error handling

Note how the toggle is not switched on error. Previously, the toggle state would change even in case of error.

Screencast.from.26-01-2024.16.25.25.webm

Executed Tests

mvn clean install \
  -Pquality,integration-tests,docker \
  -pl :xwiki-platform,:xwiki-platform-livedata-test-pageobjects,:xwiki-platform-livedata-webjar,:xwiki-platform-notifications,:xwiki-platform-notifications-test-docker,:xwiki-platform-notifications-test-pageobjects,:xwiki-platform-notifications-ui,:xwiki-platform-notifications-webjar

Expected merging strategy

• Prefers squash: Yes
• Backport on branches:
  • N/A

[surli]

I'm honestly wondering if it wouldn't be better for the long term maintenance to get rid of that, and provide a dedicated Java source for the LD. Feels like it would be easier to test / maintain, no?

[manuelleduc]

I kept that one because I considered it could be used by extensions. But yes, might not be a bad idea to provide a clean source and to move that whole one to legacy.

[manuelleduc]

Well, actually there is 3 other livetable using this results page, so we'll need to migrate them as well before being able to depracate.

[surli]

I kept that one because I considered it could be used by extensions.

I honestly doubt it but yes it makes sense to be conservative.

Well, actually there is 3 other livetable using this results page, so we'll need to migrate them as well before being able to depracate.

I was thinking about doing that for the custom notification filters: I don't recall but I guess it's same page used for those too. Actually I'm surprised: you do have filtering / sorting with that page result? Or the filtering / sorting only work on frontend with the live data here?

[surli]

If you think it's ok maybe we can do the move by steps:

1. merge that,
2. create an improvment ticket to have dedicated source for LD for those
3. open a vote to get rid of this LT results (would avoid having to maintain it on the long run)
4. migrate other LT to LD using the source from 2 and migrate again that one with the source too

[manuelleduc]

+1, I'm taking a close look at the migration, and it's not "too" difficult (modulo the random bumps you can get when migrating messy Velocity script), but this PR is already quite large, so I'm not against delaying this to another step.

[manuelleduc]

Actually I'm surprised: you do have filtering / sorting with that page result? Or the filtering / sorting only work on frontend with the live data here?

No, I just realized the mistake when looking at the migration to a LD source. Fixing that.

[manuelleduc]

Should be better with 75fd7ef

[manuelleduc]

2. create an improvment ticket to have dedicated source for LD for those

https://jira.xwiki.org/browse/XWIKI-21848