WIP: Feature flag permissions
What does this MR do?
Adds Permissions to feature flags based on protected environments.
We check if the user can change the value of feature flag environment scope. If users can deploy environment, they are allowed to edit feature flags.
We allow a user to create feature flags with any initial values. If the project has any protected environment and user didn't specify, we create scopes automatically based on other scopes. E.g. if user specified "*" => inactive, "review/*" => active
, and project has protected environment review/my-review-branch
, than default value for this scope would be active
based on "review/*" => active
rule.
We also add environment scope for every feature flag in the project when a user adds a protected environment. The logic for feature flag being active is the same as above.
We can not guarantee that all feature flags will always contain scopes per protected environment though. E.g. in the case when protected environments were disabled for a while someone was adding feature flags, and than protected environments were enabled. This situation is purely hypothetical though since feature flags and protected environments are available on the same tires.
Subsequent MR will add a migration for adding scopes for all existing feature flags.
https://gitlab.com/gitlab-org/gitlab-ee/issues/8239
-
add can_update
andprotected
to feature flag entity - needed to showprotected
badge and disabled toggles -
fix new form on frontend https://gitlab.com/gitlab-org/gitlab-ee/issues/8239#note_185644515 -
fix specs stubbed in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10096/diffs#2337c17a780da3e6d68c53be26ebac5eeae70f97_14_14 -
create feature flag scopes for a protected environment on its creation -
do the same for existing protected_environments in background migration
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation created/updated or follow-up review issue created -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Performance and testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team