## TL;DR Define the new `update_sast_vr_setting` custom ability and grant it to `maintainer`, `owner`, and `security_manager` at the project scope. No behavior change yet. ## Acceptance Criteria - [ ] New file `ee/config/custom_abilities/update_sast_vr_setting.yml` exists, modeled on `admin_vulnerability.yml`. - [ ] Ability is granted at project scope to `maintainer`, `owner` and `security_manager`. - [ ] Policy spec confirms a Security Manager, Owner and Maintainer pass `can?(:update_sast_vr_setting, project)`; Reporter and Guest do not. - [ ] No existing controller/mutation/view behavior changes (this issue is wiring only). ## Implementation Details - [x] Create `ee/config/custom_abilities/update_sast_vr_setting.yml` with: - [x] `project_ability: true` - [x] `enabled_for_project_access_levels: [25, 40, 50]` - [x] `available_from_access_level: 40` - [x] `requirements: [read_vulnerability]` - [ ] `project_permissions:`, `group_permissions:` sections naming the new ability - [ ] Add `update_sast_vr_setting` to `raw_permissions` in: - [ ] `config/authz/roles/maintainer.yml` (project + group blocks) - [ ] `config/authz/roles/security_manager.yml` (project + group blocks) - [ ] Update `EE::ProjectPolicy` if explicit rules are needed (most flows automatically via role YAMLs). ## Testing Approach - [ ] Unit tests - [ ] Integration tests - [ ] Manual validation steps ## Estimate