<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Collaborate/take over this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=601817) </details> <!--IssueSummary end--> ## Summary The Secrets Manager frontend renders actions based on page reachability and entitlement state, not on whether the current user can actually perform them. Users below the required role see buttons that can only fail: a Reporter gets **New secret** on an unprovisioned project (provisioning is Owner-only), a self-managed group Owner gets **Start trial** / **Enable with GitLab Credits** (admin-only on SM), and all of them receive a generic error that misreads a permission denial as a transient failure or resource-not-found. The backend denies correctly in every case. This is the umbrella for the frontend half of the fix: consume the backend's abilities SSOT and gate every call to action on it, showing an actionable message (who to contact) where the user cannot act. This issue was originally scoped to hiding CRUD controls (from the Professional Services closed-beta evaluation, see https://gitlab.com/gitlab-org/gitlab/-/work_items/593750#note_3222018998) but have now expanded to better fix the mismatch between frontend and backend. The backend half of that original scope shipped in !240596 (`userPermissions` on the SecretsManager GraphQL types + `404` for users without OpenBao read capability). What remains, and what this umbrella now tracks, is the frontend consuming those abilities, plus the same treatment for every other CTA discovered during self-managed E2E testing (https://gitlab.com/gitlab-org/gitlab/-/work_items/628023). ## Backend dependency https://gitlab.com/gitlab-org/gitlab/-/work_items/628837 tracks the backend SSOT for exposing the entitlement to all roles that can open the page. ~backend will also need to expose per-user abilities where the frontend can reach them. Some child items below are blocked on it; some are shippable today (noted per item). ## Scope of Work + Work Item Consolidation A lot of bugs that come up from E2E testing belong to the same family of issues that this work item aims to fix (see https://gitlab.com/gitlab-org/gitlab/-/work_items/629254#note_3840979798 for a related discussion). | Bug | State | MR | | ------ | ------ | ------ | | https://gitlab.com/gitlab-org/gitlab/-/work_items/629113 Update and align UI with the correct content based on secrets manager state | ~"workflow::verification" | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257125, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258310 | | https://gitlab.com/gitlab-org/gitlab/-/work_items/628742. Trial and add-on CTAs shown to users who cannot use them | ~"workflow::in review" | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258091, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258310, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256976 | | https://gitlab.com/gitlab-org/gitlab/-/work_items/629254 **New secret** button fires Owner-only provisioning for Reporter+. Carries the open ~UX question: gate the button, or gate the unprovisioned page entirely (access today is inconsistent — visible pre-provision, 404 post-provision until ACL grant). | ~"workflow::verification" | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256662, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256976 | | Consume userPermissions (CRUD) on the secrets table, details page, and forms — hide/disable create, edit, delete per the user's OpenBao capabilities (this issue's original scope). | Postponed for 19.6 | `createSecret` introduced in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258653 for empty state | | https://gitlab.com/gitlab-org/gitlab/-/work_items/631373 "New secret" is missing after starting the trial or enabling the add-on until the page is reloaded | ~"workflow::in review" | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258653 | | Replace the `can_manage_secrets_manager` `admin_group` proxy in `secrets_helper.rb` with the real `provision_secrets_manager` / `admin_project_secrets_manager` ability (existing TODO in code). | Tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/630533, not critical for 19.5 | | | https://gitlab.com/gitlab-org/gitlab/-/work_items/628207+ Verify current behavior; if the re-enable path is still missing, add as child (missing-CTA-by-state). | :white_check_mark: Verified in E2E | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254414 | | https://gitlab.com/gitlab-org/gitlab/-/work_items/628837#note_3841849067 On subgroups, projects, and self-managed groups that haven't provisioned the secrets manager yet, the settings section renders as an empty shell: just a title and a billing alert, with nothing the user can act on. This happens because showSettings only checks the entitlement state (trial/paid), and the one control that used to justify rendering pre-provision — the provisioning toggle — is hidden in the paid experience. | ~"workflow::in review" | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257554 | | Gap 7 from https://gitlab.com/gitlab-org/gitlab/-/work_items/629638: when the entitlement is `INELIGIBLE` but the secrets manager is already provisioned, the settings section renders in a broken state. The permissions query is denied by the policy, so the user sees the raw error (`"The resource that you are attempting to access..."`) on top of an empty permissions table — which still shows an **Add** button that can't work. **Fix direction:** hide or disable the permissions table and its **Add** button based on the backend's ability/state booleans (the "Edit permissions tab" row in the matrix above), instead of letting the components find out via a failed query. | Found during this [spike](https://gitlab.com/gitlab-org/gitlab/-/work_items/629638), not from E2E. Parked until the SSOT booleans exist. | | ~UX consideration when working on these fixes: Every denial surfaced to the user must name the cause and the actor who can help (e.g. "Contact your administrator to start a trial", as the beta banner already does) — no more generic "Try again later" / "resource does not exist". ## Current permissions matrix <details> <summary>Initial Version</summary> | Action | BE ability (grant) | Exposed to FE? | FE consumes? | Gap | |---|---|---|---|---| | Read metadata / CRUD secrets | OpenBao effective capabilities via `userPermissions` on `{Project,Group}SecretsManager` types (!240596) | ✅ GraphQL | ❌ no query selects it | FE adoption (original scope of this issue). Field is `null` pre-provision | | Start trial | `start_secrets_manager_trial` — Owner on SaaS (`owner.yml`); instance admin on SM (`global_policy.rb`); SM group Owners prevented via enrollment gate (`group_policy.rb`) | ✅ `can_start_trial` app data, policy-driven (`secrets_helper.rb`) | ⚠️ beta banner only; trial empty state ignores it | https://gitlab.com/gitlab-org/gitlab/-/work_items/628742 — shippable today | | Enable add-on | `enable_secrets_manager_add_on` — same dual grant shape | ❌ | — | Needs `can_enable_add_on` in app data (helper one-liner, policy-driven) | | Provision | Group: `provision_secrets_manager`; Project: `admin_project_secrets_manager` (`owner.yml`) | ❌ | — | https://gitlab.com/gitlab-org/gitlab/-/work_items/629254. Must be exposed **pre-provision**: app data or `userPermissions` on Project/Group types — not on SecretsManagerType, which is `null` exactly when needed | | Deprovision / disable | Group: `deprovision_secrets_manager`; Project: `admin_project_secrets_manager` | ⚠️ `can_manage_secrets_manager` = `can?(:admin_group)` proxy (`secrets_helper.rb`, existing rubocop TODO) | ✅ settings | Replace proxy with the real ability | | Edit permissions tab | `update_secrets_permission` / `delete_secrets_permission` | ❌ (FE infers from role) | — | Expose + consume | | View permissions tab | `read_project_secrets_manager` / `read_secrets_manager` (Maintainer+) | ❌ (inferred) | — | Optional | | Enroll/unenroll TLG (SaaS) | `create/delete_secrets_manager_enrollment` | ✅ `can_enroll_namespace` app data | ✅ | — | | Entitlement (banners, read-only mode) | `read_secrets_manager` gate on `Group.secretsManagerEntitlement` (Maintainer+, TLG only) | ⚠️ | ✅ where visible | https://gitlab.com/gitlab-org/gitlab/-/work_items/628837 gaps: Reporter+ gets `null`, no project-level field, personal namespaces skip the query; FE fails **open** on `null` | </details> See https://gitlab.com/gitlab-org/gitlab/-/work_items/601817#note_3851082933 for the updated version. <details> <summary>Looking for the old issue description? Click here!</summary> ## Summary Users with Reporter or Developer role can navigate to the Secrets Manager page and see the **New Secret** button and other action controls (edit, delete), even when they have not been granted the necessary permissions in the Secrets Manager settings. Attempting to create a secret results in a generic permission error, with no upfront indication that the action is unavailable. This was surfaced during the Professional Services closed-beta evaluation activity: https://gitlab.com/gitlab-org/gitlab/-/work_items/593750#note_3222018998 ## Current behavior - Reporter+ level users can navigate to the Secrets Manager page if the feature is enabled on the project/group. - The **New Secret** button is visible and the creation form is accessible. - On submit, a generic `permission denied` error is shown. - No upfront feedback indicates the user lacks the required permissions. ## Expected behavior - The **New Secret** button should be hidden (or disabled with a clear tooltip) for users who have not been granted create permissions in the Secrets Manager settings. - Similarly, edit and delete actions in the secret list should be hidden for users without the corresponding permissions. - Ideally, users with no secrets permissions at all should not be able to navigate to the Secrets Manager page, or should see a clear empty state explaining they have no access. ## Context A previous issue [#477584](https://gitlab.com/gitlab-org/gitlab/-/work_items/477584) tracked this work. It was closed after partial implementation (securing GraphQL endpoints, adding permission forms), but the frontend UX hiding of buttons based on granular permissions was explicitly deferred from GA. See the discussion in the beta activity for the decision context: https://gitlab.com/gitlab-org/gitlab/-/work_items/477584#note_2694035209 This issue tracks the remaining UX gap. ## Steps to reproduce 1. Enable Secrets Manager on a project/group. 2. Create a user with Developer role on the project. 3. Do **not** grant that user any Secrets Manager permissions in the settings. 4. Log in as that user and navigate to **Secure > Secrets**. 5. Observe the **New Secret** button is visible and the form is accessible. 6. Attempt to create a secret — observe the generic permission error. ## Proposal - Fetch granular Secrets Manager permissions for the current user on page load. - Hide the **New Secret** button if the user lacks the `create` permission. - Hide edit/delete actions in the secret list if the user lacks `update`/`delete` permissions. - Consider restricting navigation to the Secrets Manager page entirely for users with no permissions granted. </details>