Add group-scoped frontend support for policy store editor and detail
What does this MR do and why?
The policy store editor and detail pages previously only worked at the organization level. Users need to manage policies from group contexts as well, which requires the frontend to detect the namespace type and route API calls to the appropriate group or organization endpoints.
Group endpoints use REST for create/delete operations because the GraphQL mutations currently only accept organization IDs. The fetch operations (list, detail, catalogs) use new group-specific GraphQL queries.
The API function signatures now include namespace context parameters, allowing components to remain agnostic about which backend endpoint handles their requests.
References
- Part of the policy store group-scoping epic
- Depends on !254842 (merged) (Group REST CRUD endpoints) - merged
Screenshots or screen recordings
No UI changes - the pages look the same, they now work in group context
After I recorded the demo, I added an experiment badge:
How to set up and validate locally
Prerequisites
-
Enable the feature flags in Rails console:
Feature.enable(:security_policies_v2) -
Ensure you have:
- An organization with the policy store experiment enabled
- A group within that organization
- Your user has appropriate permissions (Owner or Maintainer)
Testing the List Page (group context)
- Navigate to the group's policy store list:
http://localhost:3000/groups/<group-path>/-/security/policy_store - Verify the page loads and displays policies (if any exist)
Testing the Editor - Create New Policy (group context)
- Navigate to the new policy page:
http://localhost:3000/groups/<group-path>/-/security/policy_store/new - Fill in the policy wizard:
- Select a trigger (e.g., "Deployment requested")
- Add at least one rule
- Optionally add actions
- Configure scope
- Click Save
- Verify:
- The policy is created successfully
- You are redirected to the list page with a success message
- The new policy appears in the list
Testing the Detail Page (group context)
- From the list page, click on an existing policy to view its details
- Verify the URL is:
http://localhost:3000/groups/<group-path>/-/security/policy_store/<policy-id> - Verify all policy information displays correctly:
- Name, description, type badges
- Trigger, rules, actions sections
- Scope information
- Version and timestamps
Testing the Editor - Edit Existing Policy (group context)
- From the detail page, click "Edit policy"
- Modify the policy (e.g., change the name or description)
- Click Save
- Verify:
- The update succeeds
- You are redirected to the detail page with updated information
Testing Toggle Status (group context)
- From the detail page, click "Disable" (or "Enable" if already disabled)
- Verify the status badge updates immediately
- Refresh the page to confirm the change persisted
Testing Delete (group context)
- From the detail page, click "Delete"
- Confirm the deletion in the modal
- Verify:
- You are redirected to the list page
- The policy no longer appears in the list
Comparison with Organization Context
Repeat the above tests at the organization level to ensure both contexts work:
http://localhost:3000/-/organizations/<org-path>/security/policy_storeMR 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 #627174 (closed)
