Hide segments containing expressions from disabled plugins or features

[bx80]

Description:

refs #21339
Fixes #21318

When an attempt is made to use a segment which contains expressions referencing a disabled dimension then the exception Segment '$name' is not a supported segment. is thrown.

This can happen when a plugin is disabled or if certain features which provide segments are turned off, such as the visitor profile.

For the cron-based archiving process the exception is caught and a non-fatal info message is shown.

In the Matomo dashboard segments containing unavailable expressions can still be chosen in the segment selector and doing so will result in fatal errors as API calls to retrieve segment data will encounter the Segment '$name' is not a supported segment. error and return HTTP 500 codes.

How to recreate

To recreate this issue try the following steps:

• Make sure browser_archiving_disabled_enforce = 1 is not set in config.ini.php
• Create a new segment with the definition "visitorId==4b3d9389bae51466"
• Disable visitor profiles in general settings (Live -> "Turn off visitor log and visitor profiles")
• Switch to the new segment in the dashboard
• View the goals overview page (or any other page loading widget data)
• A front end exception will be shown and an error logged Error: Segment 'visitorId' is not a supported segment.

What this PR does

This PR filters the list of segments shown in the segment selector to remove any segments which contain unavailable expressions. If the disabled plugin or feature is re-enabled then the segments will immediately be available again.

Integration tests are included which check availability of test segments for disabled visitor id, disabled user id and a disabled plugin segment.

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

[michalkleiner]

Looks good to me, failing tests are unrelated.
Let's see what @sgiehl thinks.

[sgiehl]

I had some thoughts around this topic. Did you consider the following scenario when creating/testing this PR:
A segment can be create for a specific website, but also globally. In addition a segment can be valid for one website, while it can be invalid for another. e.g. Disabling the visits log is possible globally, but also in the settings for each website.
How does the UI and archiving behave for segments that are available globally and only invalid for a specific website?

[bx80]

How does the UI and archiving behave for segments that are available globally and only invalid for a specific website?

Archiving will catch the exception thrown when trying to initialize the warning and then skip the segment, nothing has changed there.

For the UI, we're checking each segment against the current site before adding it to the segment selector, so if there is a globally available segment it will be checked for validity against the currently chosen site and only added to the site selector if it is valid. If the user then changes site the globally available segment will be checked again for the new site.

[sgiehl]

Ok. So for hiding unavailable segments from the UI the approach works nicely. In terms of archiving we might need to do some more testing. I'll merge this PR already, as we can implement further changes in a new PR if needed.