When permissions are added to a role by a developer in a branch, there are 4 types of situations:
- The object is new for the branch and permission is added to a new role
- The object is new for the branch and permission is added to an existing role
- The object existed at the start of the branch and permission is added to a new role
- The object existed at the start of the branch and permission is added to an existing role
I consider the first 3 situations happy-flow use-cases in which no extra risk is involved because either the role is new or the object is new.
The 4th situation is different because the developer has changed permissions of something that already existing without creating it. This is mostly done as an exception when ‘fixing’ permissions that were initially forgotten. The risk for this situation is bigger because maybe the object permission was not forgotten but deliberately left out for that role. Specially for column rights this could be the case. Also a developer who added a new field could use the assign permissions task on table level with the checkbox for all columns, not noticing that there were columns left out previously.
Currently it is hard to filter on just the 4th situation. When merging a branch it does give an impact overview of added permissions, but the other 3 situations generate the same type of mutations an thus a lot of noise to go through.
For us a quick win with a new prefilter on the merge impact screen that would filter on all types of access rights mutations that are added to existing objects in existing roles would be enough to integrate this in our process. Of course a new role review screen would be even better of course.
To clarify: with ‘existing’ I mean that it existed when the branch was created.