Use ProjectFeature class for all permission checks
What does this MR do and why?
This removes some duplicate logic from the ProjectPolicy and uses the methods in ProjectFeature
, (and ProjectTeam
via that).
This is done as an iterative step to help clean up the logic in ProjectPolicy
a little, before we implement Adapt visibility settings to new structure afte... (&8004).
There's lots more cleanup to be done so this is by no means an exhaustive MR, but meant to be a small MR to help us unravel some of the duplicated logic.
This MR:
- Uses
ProjectFeature::FEATURES
as the source of features in the ProjectPolicy.- After this is done, we end up with an extra condition
package_registry_disabled
, which is unused.
- After this is done, we end up with an extra condition
- Uses
ProjectFeature#feature_available?
as the interface for checking permissions. This reduces code leakage + duplication of logic
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.