Disable security policy edit menu
What does this MR do and why?
This change adds permission checking to the security policies list page. Previously, all users could see policy action buttons (like edit/delete) even if they didn't have the right permissions to use them. Now the system checks if the current user has Developer, Maintainer, or Owner roles in both the main project and the security policy project. If they don't have sufficient permissions, the action buttons are disabled and show a helpful message explaining what roles are needed. The change also updates the popover (tooltip) text to clearly indicate when actions are disabled due to insufficient permissions versus when they're disabled because a policy is inherited from a parent group. This prevents user confusion and provides clear guidance on what permissions are required to manage security policies.
References
Screenshots or screen recordings
| Description | UI |
|---|---|
| Restricted permissions | permisions.mov |
How to set up and validate locally
- Create a project inside a group. Ex:
Gitlab Org>test-project-1 - Create a project security policy. Example: Merge request approval policy
- Invite a user with a "developer/maintainer/owner" role to the project. The user is either not invited to the project group or have a group role below
developer
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.
Related to #526069 (closed)