<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=602776) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=602776) </details> <!--IssueSummary end--> <!-- Title: Merge request approvals API returns approved as true in EE Free with no approvals --> ### Summary On an EE instance without the merge request approval rules feature available, `GET /projects/:id/merge_requests/:merge_request_iid/approvals` can return `"approved": true` for a merge request that has no approvals. This is confusing for API consumers because the same response also returns an empty `approved_by` array. A script that checks the top-level `approved` field can treat an unapproved merge request as approved. 🛠️ with ❤️ at Siemens ### Steps to reproduce 1. Use an EE self-managed instance where the merge request approval rules feature is not available, for example an EE instance without a paid license. 1. Create or find a project with a merge request that has no approvals. 1. Call the merge request approvals API: ```shell curl --header "PRIVATE-TOKEN: <your_access_token>" \ --url "https://gitlab.example.com/api/v4/projects/<project_id>/merge_requests/<merge_request_iid>/approvals" ``` 1. Inspect the top-level `approved` field and the `approved_by` array in the response. ### Example Project This was reproduced locally in a GDK development environment. No public example project is available because the behavior depends on the self-managed EE licensing state. ### What is the current *bug* behavior? The API reports the merge request as approved even though there are no approval records: ```json { "approved": true, "approved_by": [], "approvals_required": 0, "approvals_left": 0, "user_has_approved": false, "user_can_approve": true } ``` The contradiction is: - `approved_by` is empty. - No user has approved the merge request. - `approved` is still `true`. ### What is the expected *correct* behavior? The endpoint should not report that a merge request is approved when no approval exists. For an EE Free or no-license instance, the response should preserve the documented and useful behavior for API consumers: ```json { "approved": false, "approved_by": [] } ``` If a user has approved the merge request, `approved` should be `true` and `approved_by` should include the approving user. ### Relevant logs and/or screenshots Local reproduction output: ```text EE=true license_present=false merge_request_approvers=false approvals_count=0 approval_feature_available=false approval_state_approved=true GET /api/v4/projects/1/merge_requests/1/approvals status=200 ``` Response excerpt: ```json { "approved": true, "approved_by": [], "approvals_required": 0, "approvals_left": 0, "user_has_approved": false, "user_can_approve": true } ``` A preliminary search did not find a clear duplicate. Related but non-duplicate issues: - https://gitlab.com/gitlab-org/gitlab/-/work_items/399170 - https://gitlab.com/gitlab-org/gitlab/-/work_items/360846 - https://gitlab.com/gitlab-org/gitlab/-/work_items/408183 - https://gitlab.com/gitlab-org/gitlab/-/work_items/9922 - https://gitlab.com/gitlab-org/gitlab/-/work_items/228924 ### Output of checks #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> Reproduced in a local GDK development environment: EE=true License present=false Merge request approval rules feature available=false </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> Not run. The issue was reproduced through the Rails application API in a local GDK environment. </pre> </details> ### Possible fixes The issue appears to come from the EE response presenter used by the merge request approvals API. When approval rules are unavailable, the rule set is empty and the rule-based approval state evaluates as approved. The endpoint should keep consistent semantics for EE Free/no-license responses: - A merge request with no approvals should return `approved: false` and `approved_by: []`. - A merge request with one or more approvals should return `approved: true` and include those approvals in `approved_by`. - Add regression coverage for the EE Free/no-license path of `GET /projects/:id/merge_requests/:merge_request_iid/approvals`. ### Patch release information for backports No patch release request at this time.