Configuring merge request "approvals_before_merge" via API is not respected in the UI

Summary

Updating a project's MR settings for approvals_before_merge via API does not affect the approval checks for the project's Merge Requests. Configuring the settings through one interface does not affect the settings that another interface acknowledges.

Steps to reproduce

  1. Create a new project
  2. Add a group as the default approvers
  3. Via API, update the approvals_before_merge to 1.
    • curl -X POST -d '{"approvals_before_merge":1}' -H 'Content-Type: application/json' -H "Private-Token: $TOKEN" https://$GITLAB_HOST/api/v4/projects/29/approvals
      • TOKEN -- Access token with API privileges
      • GITLAB_HOST -- Hostname of the enterprise Gitlab instance
  4. Via UI, go to the project's merge request approvals settings (Settings -> General -> Merge request approvals).
  5. The No. approvals required is still 0.
  6. Opening a merge request shows that no approvals are needed to merge.
  • Notes on other permutations:
    • Adjusting other merge request settings (e.g., merge_requests_author_approval) are reflected in both the UI & API.

What is the current bug behavior?

The API reports a successful update to the settings, and a GET request for the settings confirms the change occurred. Unfortunately, the UI reports that No. approvals required is a different value. Future merge requests that are opened will only adhere to the setting displayed in the UI.

What is the expected correct behavior?

  1. That the UI acknowledge the values updated via API.
  2. That merge requests opened afterwards to abide by the settings configured via API.

Relevant logs and/or screenshots

  • Screenshot of the UI, showing the merge request approvals settings

    • Screen_Shot_2019-06-08_at_12.38.00_PM

  • API payload from /projects/29/approvals

    • Screen_Shot_2019-06-08_at_12.11.17_PM

  • A similar issue that was opened up recently -- https://gitlab.com/gitlab-org/gitlab-ee/issues/12008

    • What this issue shares with 12008 is that there is a disconnect between what is configured via UI & what is configured via API.
    • A distinct difference is that 12008 configures through the UI and reads from the API. This issue specifically configures the settings via API, and none of the settings are respected in the UI.

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab application/environment info

  • GitLab Enterprise Edition 11.10.4-ee
  • I'm not personally an admin of the instance; I'd have to request them to add any additional information
Expand for output related to GitLab environment info 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

Possible fixes

None to propose.

Edited by Darren M