Ability to add and remove users to a Feature Flag to expose a feature to only those specified users
Problem to solve
We recently rolled out feature flags with the ability to turn a feature off or on. Another important capability of feature flags is to be able to set a list where, for users who have the userid(s) named, they will always see the feature in question enabled in any environment. Turning this on will allow very targeted testing using Feature Flags, and will supplement Review Apps nicely as a way to validate that changes deployed to production are working without having to jump through hoops to review them.
This is part of the Progressive Delivery MVC (&1198 (closed)), specifically the stage 1 section that's about enabling developers to do controlled rollouts.
Proposal
The Unleash client library already supports userid-based scenarios (https://github.com/Unleash/unleash/blob/master/docs/activation-strategies.md#userwithid), which sets the feature flags based on the logged in user of the remote system (i.e., not the GitLab user). This is useful in the early stages that the feature is still under evaluation, when you want for example all of your internal employees and/or beta users to access the feature. For the access, they have to register their (non-GitLab) user ID to a feature flag at first. Usually, beta users (i.e. external users) don't have direct access to a feature flag control panel so they have to contact to the company or internal employee first to be added.
- Update our implementation of the server API to support associating a userid with a feature flag
- Display the associated userids in the Feature Flag UI
- Allow adding/removing userids in the UI.
Users & Security
Because the userIDs in play are the non-GitLab users, we have limited visibility into what those might be. This is a good thing, we don't want to start pulling potentially personally identifying information into GitLab and we also don't want to bring GitLab security considerations around user management into play here.
UserID selection is based on simple string matching, as you can see how it works if you use the Unleash UI here: https://gitlab.com/gitlab-org/gitlab-ee/uploads/c5752845de124863b0d2889b28c9d244/image.png
The Unleash API does not support pattern matching like *@example.com via this functionality, so we need to ensure this interface allows for pasting lists of users into it rather than requiring lots of individual clicking to add and remove people.
Interactions
Specifying explicit userIDs that will have a feature enabled is more specific than a general rule that the feature flag is off, or that it is doing a 50% rollout - therefore, if a userID rule is set then it will take precedence over other rules. This follows the behavior of the Unleash API but should be clear to users.
UX Proposal
- User can add a list of comma-separated user ids
- User can press enter or click Add button to add user ids
- User ids are displayed as badges
- User can click the badge 'x' to remove an id
- Users can clear all ids with the clear all button
- Ids can have a max length of 256 characters
- Disable the User ID Input if the user doesn't have permissions for all the environments shown
| Desktop | Mobile |
|---|---|
 |
 |
| User id max length error | User Id badge wrap |
 |
 |
Auditing
These new userID change events must be added to the already in-place auditing system for feature flags as well.
What does success look like, and how can we measure that?
- number of times someone modified the user id list for feature flags in a project
- need to do analysis of current feature engagement with feature flags to determine target number for engagement metric above
- don't know yet how much we expect this to drive, but it should be significant enough to drive MAU for Release towards the 8% improvement in concert with https://gitlab.com/gitlab-org/gitlab-ee/issues/8240, which enables % rollout.
Concerns
This capability will allow the users to always see the feature in question enabled in any environment. This introduces a use case where someone can set a user to view the change in the environment even if they don't have permissions to this environment.
To address this concern, we will disable the User ID Input if you don't have permissions for all the environments shown, similar to how the feature flag name and description is disabled in the same situation.