Wrap the approvals required in a fallback rule
What does this MR do?
This allows us to treat the values from
Project#approvals_before_merge
and
MergeRequest#approvals_before_merge
the same way as other approval
rules.
It also makes sure the minimum approvals required in this case, is
equal than or more what was defined on a single rule in the project if
there was a single rule.
If there was no single rule, we use the approvals_before_merge
attribute of Project
This is required to keep approvals working for users on GitLab Starter, those are only allowed to use 1 approval rule, that rule could be overridden in the merge request itself. It they want to override a project rule without selecting users, we need to correctly fall back to that.
What are the relevant issue numbers?
This should help @pslaughter in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9488/
He discovered the regression there
Does this MR meet the acceptance criteria?
- [-] Changelog entry added, if necessary
-
Documentation created/updated via this MR -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Tested in all supported browsers -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
Conforms to the database guides -
Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process. -
EE specific content should be in the top level /ee
folder -
For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan? -
Security reports checked/validated by reviewer