Description
(This complements #16408 and closes the loop between scanner rules and their actions, and restrictions and their impact)
When a restriction is added automatically due to a scanner rule action, we currently log this with a descriptive reason:
Automatically added because of a match by rule "<rulename>" on Addon <addon_id> Version <version_id>.
In order to better understand and assess which and why a restriction has been added automatically, we'd like to store and expose a link between the version ID and the rule ID. (The above could be parsed to identify the version, but the rule name is not unique and in fact some rules have identical names.)
A list of restriction instances on the reviewer tools page linking to the instances on the admin could be an option, but open to others as well.
Acceptance Criteria
┆Issue is synchronized with this Jira Task
Description
(This complements #16408 and closes the loop between scanner rules and their actions, and restrictions and their impact)
When a restriction is added automatically due to a scanner rule action, we currently log this with a descriptive reason:
In order to better understand and assess which and why a restriction has been added automatically, we'd like to store and expose a link between the version ID and the rule ID. (The above could be parsed to identify the version, but the rule name is not unique and in fact some rules have identical names.)
A list of restriction instances on the reviewer tools page linking to the instances on the admin could be an option, but open to others as well.
Acceptance Criteria
┆Issue is synchronized with this Jira Task