Approving a MR then *editing* a file doesn't reset the approvals

Summary

The team member who reviews the merge request can apply changes through the gitlab UI and execute the merge request, thus bypassing the approval flow and the four eyes principle for code that is pushed to a protected master branch.

Steps to reproduce

needed: master branch that is protected
A merge request for code that is ready to be pushed to master.

What is the current bug behavior?

scenario 1 (correct behavior):
Team member A created branch: a_branch and creates a merge request.
Team member B approves, but then pulls the code, makes a change and pushes it again, the approval is revoked. (correct behavior)

scenario 2 (incorrect behavior):
Team member A created branch: a_branch and creates a merge request.
Team member B edits a code file via the UI on GitLab, saves it, then approves it and merges the code. (thus bypassing the four eye principle and can potentially insert malicious code in production)

What is the expected correct behavior?

Scenario 2 should also reset the approval, the person who last committed a change should not be able to approve the merge request anymore.

Edited Aug 27, 2018 by Oswaldo Ferreira
Assignee Loading
Time tracking Loading