Show a summary of new features #18065

Description:

Fixes #16805

Adds a "What's new" notification icon to the admin top menu (new material icon added to the matomo font)
Defines a new event CoreAdminHome.getWhatIsNew which plugins can register for and use to provide an array of items representing their significant changes. These will then be displayed on the "What's new" popup.

This approach leaves individual plugins responsible for updating or removing their "What's new" entries. Perhaps there should be some sort of expiry option? If a plugin adds a "What's new" entry but then isn't updated for 5 years then we wouldn't really want that 5 year old "new" entry to still be shown.

Review

• [ ] Functional review done
• [ ] Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• [ ] Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• [ ] Security review done
• [ ] Wording review done
• [ ] Code review done
• [ ] Tests were added if useful/possible
• [ ] Reviewed for breaking changes
• [ ] Developer changelog updated if needed
• [ ] Documentation added if needed
• [ ] Existing documentation updated if needed

After discussions with @tsteur and input from @sgiehl, I plan to make the following changes:

• Load the new features/changes from a JSON file in each plugin rather than have plugins pass changes via events.
  • When any update or plugin activation/deactivation happens then check each plugin for an optional changes.json file and merge them all together into an single combined changes.json file.
  • Have each change require a date in additional to the name, description and link, so that changes can be shown in date order.
  • The "What's new" overlay should then be populated from the combined changes.json file on demand.
  • For expiry of old changes, implement a rolling window where a minimum quantity of the most recent (20?) updates are always shown no matter how old they are, after which any updates older than (180?) days are not shown.
• Store the date that each user last viewed the "What's new" overlay.
• Change the menu bar icon to material icon "bell" same as cloud (the current icon-new_releases looks too similar to help).
• Show an indicator on the "What's new" menu icon if the date of the combined changes.json file is newer than the date the user last viewed "What's new" (ie. there are changes they haven't seen yet). Using material icon "bell ringing" as the indicator in place of the normal "bell" icon.
• Add a UI test for the "What's new" overlay (will need to mock in a consistent set of changes).

@bx80 haven't had a closer look yet. But there might be a disadvantage with this implementation. If the changes are sorted by the date defined in the json file, that wouldn't reflect when those changes got available in the actual Matomo instance. If you for example install/update a plugin that was already available for quite a while the changes might not even be visible when there are newer changes in other components, right?

If the changes in a newly installed plugin were older than the 180 day cut off then, yes they might not be shown, if they are within 180 days then they will always be shown no matter how many other changes there are (might have to scroll though!) I'm not sure there is a perfect solution here without tracking which user has seen which individual change, which is probably an overkill.

We could start tracking the plugin install/update date and then also show the last x changes for plugins that were installed or updated in the last 30 days no matter how old those changes are, they'd appear at the bottom of the list if the dates were a while ago, but they at least be there. There would need to be further checks for fresh installs to prevent every plugin getting on the list because they were all just installed. Maybe the installed/updated date would need to be more recent that the Matomo setup date. This adds a fair bit of complexity,

I don't think we could use solely the plugin install/update date to determine the change list order as eventually a single plugin could have hundreds of changes defined going back years and we wouldn't want all of them to be top of the list just because there was a minor update last week.

This issue is in "needs review" but there has been no activity for 7 days. ping @matomo-org/core-reviewers

@bx80 are you still working on this issue? I haven't been reviewing as I vaguely remember we talked about potentially somehow slightly changing it to mark at what time the what's new was seen and then potentially remember that. If there is an efficient solution for it without storing heaps of information. Or maybe we just need to push all "what's new" entries into a table after all? Meaning eg when installing a plugin we look for new "what's new" entries and push them into the database and show them that way in the right order or something?

I'll remove the "needs review" label for now. Feel free to add it again if it's ready to review.