Draft: Secrets Manager: Gate UI actions on granular permissions (frontend only)

Mireya Andresrequested to merge
duo/feature/601817-secrets-manager-frontend-permissions into master

What does this MR do and why?

Splits the frontend changes from !240596 (merged) into a separate MR, as requested by @mgandres. The backend MR (!240596 (merged)) should be merged first to ensure the userPermissions GraphQL fields are available before the frontend code is deployed.

This MR gates Secrets Manager UI actions on granular permissions fetched from the userPermissions field on the secrets manager status query. isReadOnly takes precedence over all permission checks (archived/marked-for-deletion projects still hide all actions).

Changes

GraphQL queries:

  • Update getGroupSecretManagerStatus and getProjectSecretManagerStatus to include userPermissions fields

SecretsApp:

  • Propagate canCreateSecret, canUpdateSecret, canDeleteSecret via Vue provide (defaults to true for backward compatibility with old backend responses)
  • Read userPermissions from the status query response and update the provided values

SecretsTable:

  • Gate New secret button (empty state + table header) on canCreateSecret
  • Gate actions column on canUpdateSecret || canDeleteSecret
  • Pass canUpdate/canDelete props to SecretActionsCell

SecretActionsCell:

  • Add canUpdate and canDelete props (default true)
  • Conditionally render Edit and Delete items based on props

SecretDetailsWrapper:

  • Inject canUpdateSecret and canDeleteSecret
  • Gate Edit button on canUpdateSecret (and !isReadOnly)
  • Gate Delete dropdown on canDeleteSecret (and !isReadOnly)

SecretFormWrapper + SecretForm:

  • Inject canCreateSecret and canUpdateSecret in wrapper
  • Compute isPermissionDenied based on isEditing and the relevant permission
  • Pass isPermissionDenied to SecretForm
  • Show non-dismissable danger alert when isPermissionDenied
  • Disable all form fields and submit button when isPermissionDenied

Tests:

  • Add/update Jest specs for all changed components covering all permission combinations and isReadOnly override behavior

References

Screenshots or screen recordings

Before After
New Secret button and Edit/Delete actions visible to all users with Reporter+ role New Secret button and Edit/Delete actions hidden from users without the corresponding granular Secrets Manager permission; form fields disabled with alert when lacking create/update permission

How to set up and validate locally

  1. Enable the secrets manager for a project/group.
  2. Log in as a user with Reporter role (no granular secrets permission granted).
  3. Visit the Secrets Manager page — the New Secret button and action dropdown should be hidden.
  4. Grant the user a granular create/update/delete permission via the Secrets Manager permissions UI.
  5. Verify the corresponding UI elements appear.
  6. Visit the /new form without create permission — form fields should be disabled with a warning alert.
  7. Visit the /edit form without update permission — form fields should be disabled with a warning alert.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports