Approval rules with users that have their access revoked could become impossible to satisfy
<!--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> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=34548) </details> <!--IssueSummary end--> ### Summary When creating an ApprovalRule (`ApprovalProjectRule` or `ApprovalMergeRequestRule`) and removing access from the users/groups who are supposed to approve for that rule, it becomes impossible to satisfy the rule. ### Steps to reproduce 1. Add a user as developer to a project 1. Create an approval rule with that requires 1 approval and link that developer to the rule 1. Remove the developer from the project ### Example Project https://gitlab.com/reprazents-test-space-renamed/working/merge_requests/2 This merge request cannot be approved by `@toon`, so it can never be merged ### What is the expected *correct* behavior? The rule does not display Toon as a developer, allowing the other users, if any to approve the merge request ### Possible fixes It think we should filter out ineligible approvers from `ApprovalWrappedRule#approvers`, that would allow any other user linked to the rule to still approve. If the rule becomes impossible to satisfy, we should display a warning asking to update the rule.
issue