Rename custom_roles_for_protected_branches_enabled to custom_roles_licensed

Joe Woodwardrequested to merge
duo/feature/594891-rename-custom-roles-licensed into master

What does this MR do and why?

Follow-up to !251222 (merged) (removes the custom_roles_for_protected_branches feature flag).

That MR kept the custom_roles_for_protected_branches_enabled name (gon key, data attribute, Vue prop, and the matching EE::ProtectedBranchAccess#custom_roles_for_protected_branches_enabled? Ruby predicate) as-is to stay focused on removing the flag. The name is now misleading since it's purely a licence check (group.licensed_feature_available?(:custom_roles)), not a feature flag.

This renames it to custom_roles_licensed / customRolesLicensed everywhere:

  • EE::ProtectedBranchAccess#custom_roles_for_protected_branches_enabled? and its call sites (EE::Types::BranchProtections::BaseAccessLevelType, EE::API::Entities::ProtectedRefAccess)
  • The gon key pushed by EE::Groups::Settings::RepositoryController
  • The data attribute built by EE::Projects::Settings::BranchRulesHelper
  • The Vue provide/inject prop threaded through mount_branch_rules.js into access_levels_drawer.vue

Also renames two frontend spec titles that still said "the feature flag is disabled" even though the prop is now a pure licence signal.

Split out from !251222 (merged) to keep that MR focused on the flag removal itself (flagged as large by Danger).

Screenshots or screen recordings

N/A - internal rename only, no behavior change.

How to set up and validate locally

  1. Visit a project or group's protected branches settings with a licence that includes custom roles.
  2. Confirm the "Custom roles" section still renders in the access levels dropdown.

Merge request reports