Skip to content

Refactor vulnerabilities permissions

Jarka Košanová requested to merge 388156-manage-vuln-refactor into master

What does this MR do and why?

This MR consolidates create_vulnerability and admin_vulnerability into admin_vulnerability permissions. We also add read_vulnerability.

The reason is that we agreed that for custom roles in general we will have two basic abilities, read_* and admin_*. For vulnerabilities, at least for now, there is no difference between access to admin or read. But we should keep this unified across the different permissions.

There will be follow-up MRs with the rest of the permissions - those related to vulnerability_feedback (at least 4 of them, different access, therefore a separated MR probably with different permission), *_vulnerability_export (more complex due to the author check) and admin_vulnerability_*_links (additional checks).

Before

:create_vulnerability=>[[:prevent, #<Rule archived>], [:enable, #<Rule can?(:read_security_resource)>], [:prevent, #<Rule all?(auditor, ~developer)>], [:prevent, #<Rule read_only>]],
:admin_vulnerability=>[[:prevent, #<Rule archived>], [:enable, #<Rule can?(:read_security_resource)>], [:prevent, #<Rule all?(auditor, ~developer)>], [:prevent, #<Rule read_only>]],

After

:manage_vulnerabilities=>[[:enable, #<Rule can?(:read_security_resource)>], [:prevent, #<Rule all?(auditor, ~developer)>]]}

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #388156 (closed)

Edited by Jarka Košanová

Merge request reports