Add more options for global URL parameter exclusions

[caddoo]

Description:

This PR introduces configurable exclusion types for query parameters, offering users predefined options to tailor which parameters are excluded from tracking and reporting. Previously, users could only manually define a custom list of exclusions. Now, with this addition, we provide options that cater to broader needs, such as excluding common PII (Personally Identifiable Information) parameters, to make configuration easier and more accessible.

Key Changes and Decisions

• Original Intention for Parameter Retention: Initially, I considered allowing excluded parameters to remain in place when switching between non-custom exclusion types. This would let users easily toggle exclusion types without needing to reconfigure the list. However, to maintain backend simplicity, I opted not to retain excluded parameters across types.

• Backwards Compatibility: This update is designed to be backwards compatible. If a user already has custom exclusions configured, the system will infer the exclusion type as "custom," ensuring that existing setups continue to function seamlessly without manual adjustments.

• New Vue Component – ExcludedQueryParameterSettings: I created a dedicated Vue component to handle the exclusion configuration, as the ManageGlobalSettings component had become quite large and was handling multiple responsibilities. This new component helps isolate exclusion-related logic, making the codebase easier to maintain and extend.

• Duplication of Exclusions Type List: The list of exclusion type parameters appears in both the backend and frontend. I chose to keep them separate for better readability and maintainability, especially from a development perspective. Since the list of excluded parameters is unlikely to change frequently, this approach should not introduce significant maintenance overhead.

• Tracker Cache Expiry: After setting the exclusion type, I've expired the tracker cache. I'm not sure if this is needed?

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

[sgiehl]

@caddoo As you've requested a review, I've decided to roughly look through the changes and already leave some comments/thoughts even though the PR might not yet be fully finished.

[mneudert]

Suggested change

	if ($globalSettings['exclusionTypeForQueryParams'] !== 'custom_exclusions') {
	if ($globalSettings['exclusionTypeForQueryParams'] !== SitesManager::URL_PARAM_EXCLUSION_TYPE_NAME_CUSTOM_EXCLUSIONS) {

We should prefer the constant if we have it.

Though I am wondering why we need that check here, and not also in another place where the query parameters are accessed:

matomo/plugins/SitesManager/SitesManager.php

Lines 335 to 342 in c5d3fad

	public static function getTrackerExcludedQueryParameters($website)
	{
	$excludedQueryParameters = $website['excluded_parameters'];
	$globalExcludedQueryParameters = API::getInstance()->getExcludedQueryParametersGlobal();
	$excludedQueryParameters .= ',' . $globalExcludedQueryParameters;
	return self::filterBlankFromCommaSepList($excludedQueryParameters);
	}

Is there any special case where these two areas should differ in a way that cannot be managed inside the API methods?

[caddoo]

Good point, the controller should be dumb, so I've removed that check. The API handles this already. Take a look and let me know if that's what you are thinking, and you can resolve the thread.