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