<!--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> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=32558) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=32558) </details> <!--IssueSummary end--> The following discussion from !17466 should be addressed: - [ ] @stanhu started a [discussion](https://gitlab.com/gitlab-org/gitlab/merge_requests/17466#note_220352760): (+2 comments) > I'm not completely sure I understand why we need to do this. If you have an `any_approval` rule, this could potentially create hundreds of rows for every merge request. Do we want to limit this to regular approval rules (in another MR)? Igor: actually for `any_approver` rule `users` and `groups` are empty, so it doesn't create any rows. but since we're running this code only when `merge_request.approval_rules.regular.exists?`, then it probably makes sense to limit it only to regular rules. @lulalala wdyt? Mark: This code is to keep a finalized state so future group changes will not affect past approval state. It's only for log keeping. In that sense I would prefer doing it to all types of rules except not `any_approver`. But there is no perceived concern yet if we don't do log keeping like this, I did this as a safety net. So it's open for debate if performance is a concern.