Remove the dap_powered reviewer assignment strategy from project settings and the API
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Phase B. Blocked by the Phase A issues: #607673, #607674, #607675, #607676, #607907.
Problem
This is the change @phikai asked for in note 3562765776: "Remove the current settings for setting this up and switch to flow".
Two config surfaces exist for one feature. Remove the project setting so the only setup path is enabling the flow and creating a trigger.
Implementation — complete inventory (verified)
View
ee/app/views/projects/settings/merge_requests/_reviewer_auto_assignment_settings.html.haml — delete line 3 (dap_available = ...) and the whole if dap_available radio branch (lines 15-27); the file collapses to the checkbox branch (current lines 28-34, un-nested). Rendered from app/views/projects/settings/merge_requests/show.html.haml:19 via render_if_exists — no change there.
Orphaned translations to drop from locale/gitlab.pot (regenerate): MergeRequests|Assign reviewers with GitLab Duo Agent Platform, MergeRequests|Recommends the minimum number of reviewers required to satisfy each approval rule., MergeRequests|Reviewer assignment strategy, MergeRequests|Assign all code owners as reviewers, MergeRequests|Assign every code owner defined in your CODEOWNERS file., MergeRequests|Do not assign reviewers automatically.
REST API
ee/lib/ee/api/helpers/projects_helpers.rb:70 — change values: %w[disabled code_owners dap_powered] to %w[disabled code_owners] and update the desc string. Grape's values: whitelist is what returns 400 on a rejected value. No other API change:
- the
update_params_at_least_one_ofentry (line 117) and the license filter (lines 155-160) stay as-is; ee/lib/ee/api/entities/project.rb:70(read exposure) is unaffected;- controller (
ee/app/controllers/ee/projects/settings/merge_requests_controller.rb:38, 110-112) needs no change — the permitted attribute stays forcode_owners; - GraphQL:
reviewerAssignmentStrategywas never exposed, no change needed (verified — no field anywhere inapp/graphql,ee/app/graphql, or the reference docs).
Docs shipped in this MR (REST surface only; user docs are #607680)
doc/api/projects.md — remove dap_powered from the attribute descriptions at lines 319, 760, 1142, 1606, 2218, 2444 and add a history bullet next to the existing one at ~2349. The OpenAPI specs (doc/api/openapi/openapi_v2.yaml:71669, openapi_v3.yaml:105102 — the two enum: blocks) are regenerated.
Specs
ee/spec/views/projects/settings/merge_requests/_reviewer_auto_assignment_settings.html.haml_spec.rb— delete the "available → 3 radios" contexts (lines 52-90); keep and un-gate the checkbox context.ee/spec/requests/api/projects_spec.rb:2532-2566— the existing "rejects'bogus'with 400" example already exercises the whitelist; add an explicitdap_powered → 400example since that's the behaviour change clients will hit.- No changes needed: controller spec (only uses
code_owners/disabled), CE key-parity spec (spec/requests/api/projects_spec.rb:3014), model specs.
Deliberately not in scope (so rollback stays a plain MR revert and existing rows keep working)
- the
dap_powered: 2enum value stays (app/models/project_setting.rb:25) - the DAP branch in
MergeRequests::AutoAssignReviewersWorkerstays - existing rows keep working
Note on the API
reviewer_assignment_strategy was never feature-flag gated in the REST API — any project with the code_owners licensed feature could set dap_powered. Rejecting the value is a behaviour change for API clients, so it needs a changelog entry even though the feature is Beta and flag-gated in the UI.
Acceptance criteria
- Settings page shows only the code-owners checkbox, for all projects
-
PUT /projects/:idwithreviewer_assignment_strategy=dap_poweredreturns 400, with a spec asserting it - Projects already on
dap_poweredcontinue to behave as before, untouched -
doc/api/projects.mdno longer listsdap_powered; changelog entry for the API change