Add feature flag permissions
Problem to solve
In order to actually use feature flags in production environment flows, being able to control the permissions on a per-environment basis is incredibly important.
Permissions need to be definable on a per-environment basis. For example, review apps may be a free for all, stage may be controlled to developers-only (generally wide access but not everyone), and production/performance environments may be restricted to just a handful of specific people - not even a role like maintainer may be granular enough for an environment like that.
A key user for this feature is our own Delivery team as we look to replace the existing feature flags system we are using with our own feature.
- Protected environments receive an explicit entry in the environment specs list. Because these are exact matches, there's no way for any other rule to override them.
- The permission to edit the feature flag settings for protected environments should require the same permission to deploy to the protected environment.
Acceptance Criteria and Mockups
- When user adds a protected environment, we add a new environment_scope to all feature flags in the project. These by default follow the best matching already existing rule (so, if
*is the best matching rule and is set to off, then the new protected environment is set to off. At that point, however, they become independent.
- When we create new feature flag it got environment_scope per protected environment. This should follow the
- User can not rename or edit the description of a feature flag if
projecthas at least one protected environment and user doesn't have access to all of them. The input fields in the form should be displayed as disabled, and a helper message is displayed informing why that happens and what actions to take.
- User can not delete feature flag if
projecthas at least one protected environment and user doesn't have access to all of them. The delete option in the overview list of feature flags should be displayed as disabled.
Feature Flag view
- Protected environments are listed in individual rows under the 'Target Environments' section. Protected Environments should be displayed on the list by default under the
* (All Environments)option.
- A label reading 'Protected' is displayed next to protected environments.
- Rules for Protected Environments cannot be overridden.
- Given the user has permission to manage the protected environment: User can set a status individually per protected environment.
- Given the user does not have permission to manage the protected environment: User sees the protected environment listed, but each row should be displayed as
disabled. No interaction with the row or toggle button should be allowed. The cursor should be set to
cursor: not-allowed;. The user cannot set the status per protected environment.
|Listed protected environments||Protected environment cannot be edited. Toggle is disabled|
|User can not rename or edit the description of a feature flag||User can not delete feature flag|
Protected Environments view
- On the 'Protected Environments options under CI/CD Settings, a helper text is added to the dropdown option that currently reads Allow to deploy
- A helper text is added to the form, under the label 'Allowed to deploy'. It reads 'Choose who is allowed to deploy and manage Feature Flag settings'
- Once a user is selected in the field, and the form is saved, this user should be able to deploy and also manage feature flags on protected environments.
|settings > ci/cd > protected-environments|
What does success look like, and how can we measure that?
If successful here, this should unlock the ability of our own Delivery team to be able to use our feature flag capability in production for GitLab itself.
Links / references