Declare assignable_when conditions on system hook consumers

What does this MR do and why?

This MR is one of seven that split !253276 (merged) into pieces that each need only Authorization approval plus at most one other CODEOWNERS section. This one needs Authorization and Webhooks.

A consumer earns a condition tag only when it rejects every request from a caller who does not meet the condition, for every parameter. Partial checks, feature flags, and license checks do not count. The admin condition covers authenticated_as_admin! checks and admin-only global abilities. Nothing changes at request time. The only effect is that the token creation UI stops offering a permission at boundaries where the current user does not meet the condition.

This MR tags 2 REST consumers (6 tags) with the admin condition: lib/api/system_hooks.rb and lib/api/hooks/test.rb. 4 YAML files gain assignable_when: admin: integrations/webhook/create, delete, read, and trigger.

The hooks URL variables and custom headers concerns share one decorator across instance, group, and project mounts, so their admin-only instance variants stay untagged here.

References

Screenshots or screen recordings

No UI changes in this MR.

How to set up and validate locally

  1. Run bundle exec rake gitlab:permissions:validate. It passes.

  2. Remove the assignable_when: block from config/authz/permission_groups/assignable_permissions/integrations/webhook/read.yml and run the task again. It fails and lists the consumer in lib/api/system_hooks.rb with Consumer conditions: [admin]. Restore the block.

  3. Enable the granular_personal_access_tokens feature flag, then query the GraphQL accessTokenPermissions field (or open the fine-grained token creation page) as a regular user and as an administrator, and compare the boundaries returned for read_webhook. The regular user does not get INSTANCE.

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.

Edited by Alex Buijs

Merge request reports

Loading
Loading