[FF] feature_flag_management_permissions -- restrict feature flag management by minimum role

Summary

Roll out feature flag management permissions currently behind the feature_flag_management_permissions feature flag.

• DRI: @trizzi

Note

Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. Feature flag controls · Feature flag lifecycle

What could go wrong?

The flag gates a ProjectPolicy restriction on the create_feature_flag, update_feature_flag, admin_feature_flag, destroy_feature_flag, and admin_feature_flags_user_lists abilities.

Blast radius is bounded by the new project_settings.feature_flags_minimum_role column, which defaults to developer — the role that can already manage feature flags today. Enabling the flag therefore changes nothing until a project owner or maintainer opts in by raising the setting. No data is written or migrated by the flag.

The failure mode to watch for is over-restriction: members who should be able to toggle flags being denied. That surfaces as 403 responses on the feature flag REST endpoints (/api/v4/projects/278964/feature_flags) and on Projects::FeatureFlagsController.

Note that at the time this issue is opened, the setting is not yet writable through the API or UI (that lands in follow-up MRs), so the flag can be enabled safely well ahead of any project being able to change its value.

Rollout

Run all production /chatops in #production and cross-post the results to the groupenvironments team channel. Background: incremental rollout process, feature actors.

Non-production

/chatops gitlab run feature set feature_flag_management_permissions 50 --actors --dev --pre --staging --staging-ref
/chatops gitlab run feature set feature_flag_management_permissions true --dev --pre --staging --staging-ref

Production — percentage rollout (wait ≥15 min between steps, watch dashboards):

/chatops gitlab run feature set feature_flag_management_permissions <percentage> --actors

Or target specific actors instead:

/chatops gitlab run feature set --project=gitlab-org/gitlab feature_flag_management_permissions true
/chatops gitlab run feature set --group=gitlab-org feature_flag_management_permissions true
/chatops gitlab run feature set --user=trizzi feature_flag_management_permissions true

Before global rollout

Confirm the relevant gotchas before going to 100% — see enabling a feature for GitLab.com:

• Docs + version history updated — docs land with the API/UI MRs, since the setting is not writable in the backend-gate MR
• Breaking changes announced, if any — not expected, the default preserves current behaviour
• Change management issue opened, if required
• External API consumers handled with a fail-open mechanism, if applicable

Cleanup

Remove the flag once deemed stable — see cleaning up. Remove the flag and its YAML definition from the codebase, then:

/chatops gitlab run release check <merge-request-url> <milestone>
/chatops gitlab run feature delete feature_flag_management_permissions --dev --pre --staging --staging-ref --production

Rollback

/chatops gitlab run feature set feature_flag_management_permissions false                                         # production
/chatops gitlab run feature set feature_flag_management_permissions false --dev --pre --staging --staging-ref     # non-production
/chatops gitlab run feature delete feature_flag_management_permissions --dev --pre --staging --staging-ref --production  # remove entirely