- 2025.4.1, in zip. Also in earlier versions
Hi there,
We’ve been administering this instance for quite some time. Originally, it operated in Standard mode, but it was later upgraded to MQR mode.
As a best practice, we usually create a copy of the Sonar Way quality profile, set it as the default, and use that copy to protect against unexpected changes during upgrades. When rule updates are needed, we typically use the profile comparator to review and decide whether to upgrade, activate, or deactivate specific rules.
However, we’ve encountered an issue with some profiles containing modified rules. Specifically, even after setting the recommended severity, the rule still appears in the list of rules to be modified.
Activating or deactivating the rule doesn’t resolve the discrepancy.
To investigate further, I retrieved the comparison data using the Web API, and here’s an example of what we found:
[*] Modificar:
[-] Web:S6848 - Non-interactive DOM elements should not have an interactive handler
left: {'severity': 'MINOR', 'impacts': [], 'params': {}}
{
"severity": "MINOR",
"impacts": [],
"params": {}
}
right: {'severity': 'MAJOR', 'impacts': [], 'params': {}}
{
"severity": "MAJOR",
"impacts": [],
"params": {}
}
The comparator indicates a severity mismatch. However, in MQR mode, rule severity is no longer the key property; we now rely on impacts. And as far as we understand, severity cannot be changed in MQR if it was already customized before switching from Standard mode.
Recreating the profile from scratch isn’t an option, since the customer depends on the changelog to track rule modifications.
Switching back to Standard mode just to update the severity — and then returning to MQR — feels risky, as we’re unsure of the side effects.
What would you recommend in this case? Is there a supported way to resolve this kind of mismatch in MQR mode without losing changelog history or breaking the profile?
Regards,


