## Summary `admin_project_secrets_manager` and `create_project_secrets` say yes for a personal-namespace project whenever the resolved entitlement permits writes (self-managed: the instance entitlement; a personal namespace has no root group of its own). But `SecretsManagement::ProjectSecretsManagers::InitializeService` unconditionally refuses to provision a project in a user namespace: ```ruby # ee/app/services/secrets_management/project_secrets_managers/initialize_service.rb def ensure_secrets_manager_allowed_on_resource if resource.namespace.user_namespace? return ServiceResponse.error(message: 'Secrets manager is not available for projects in user namespaces.') end ServiceResponse.success end ``` So the ability layer and the service layer disagree: the ability can say "you may provision this," and provisioning still fails. This is the same class of bug !256662 was opened to fix (frontend showing an action that the backend will refuse), just one level deeper: here the *ability itself* is the thing giving the misleading answer, not the frontend's interpretation of it. Not a new problem. `ee/app/helpers/ee/projects_helper.rb`'s `canManageSecretsManager` already wraps `admin_project_secrets_manager` and has the same gap; it just hasn't been noticed because nothing currently renders differently based on it for personal-namespace projects. ## Where this came from Raised by @mgandres in review on !256662 (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256662#note_3882116251), which added a `can_provision`/`can_create_secret` pair of booleans to the Secrets Manager UI app data. That MR did not change `ProjectPolicy`, so this gap is pre-existing, not introduced there. Her follow-up comment (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256662#note_3883750734) raised two more angles worth checking here: 1. Whether the *mutation* (`ProjectSecretsManagerInitialize`) already rejects personal namespaces cleanly, separately from the service. 2. Whether other UI that reads `canManageSecretsManager` (e.g. deciding whether to show Secrets Manager settings at all) has the same unactionable-UI risk. ## What's already true today (verified) - The mutation does surface the service's rejection as a real error (`result.message`), so a user who clicks through on a personal-namespace project gets an explicit error, not a silent no-op or a 500. This is not a security hole; it's an unactionable-looking CTA with a confusing recovery message. - `ee/app/policies/ee/project_policy.rb` has no `user_namespace?` condition anywhere in its Secrets Manager rules. Personal-namespace projects fall through to the same role x entitlement rules as group projects. - Group-level abilities (`provision_secrets_manager`, `create_secret`) aren't affected: groups are never personal namespaces. ## Proposal (needs discussion, not pre-decided) Pick one: - **Add a `~user_namespace` condition to `ProjectPolicy`** that prevents `admin_project_secrets_manager` (and maybe `create_project_secrets`, `create_secrets_manager_api_jwt`, etc.) on personal-namespace projects. Matches the service's rule at the ability layer, so every consumer (this MR's `can_provision`, `canManageSecretsManager`, future GraphQL `userPermissions`) gets the right answer for free. - **Or leave the ability alone and have each consumer special-case personal namespaces**, the way !256662 already does for the billing booleans (`can_start_trial`, `can_enable_add_on` return `false` for personal namespaces by checking `root_namespace.is_a?(Group)` before calling `can?`). The first option is smaller in the long run but is a behavior change to an ability with existing consumers (`canManageSecretsManager` on the project settings permissions page), so it needs its own review of what currently renders there for personal-namespace projects, and whether hiding "manage secrets manager" from the settings page for a personal-namespace project owner is desired or a regression. ## Also worth checking while in here - Does `secrets_manager_available_for_project?` (`ee/app/helpers/secrets_management/enrollment_helper.rb`) or `project_permissions_panel_data`'s `isSecretsManagerAvailable` show the Secrets Manager settings section for a personal-namespace project at all today? If it does, and provisioning always fails there, that's the concrete "unactionable UI" instance Mireya asked about. - Whether this should fold into https://gitlab.com/gitlab-org/gitlab/-/work_items/628837's ability SSOT work, since that's already the tracked place for entitlement/availability consistency across roles. ## Related - Related to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256662 - Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/601817 - Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/628837