As a result of the discussion around enhancements to the gitlab~2492649 for sorting and filtering reviewers, it is likely that we'll need to change the way the dropdowns get their lists of eligible reviewers. ### High level Right now, the dropdowns are basically populated with a single list of "all reviewers." That list is then filtered - if it's in the `Assign` side panel - to only show the users from that list who are eligible for the given approval rule. Additionally, the only assignment endpoint expects the _full list_ of reviewer assignments, and can't take single-user add/remove calls via something like a `PATCH` request. In the near future, we may wind up with a new endpoint that will return users sorted according to whatever algorithm we implement. ### Updates There are a number of refactors we need to do to make this work most effective: - Allow arbitrary counts of users to be removed / added to the reviewer assignees list via the endpoint - Having to collect each dropdown as an edit to the complete list and then submit a full overwrite is a hacky workaround to an outdated model of how these assigments used to work (a single dropdown). - Allow more than 20 results OR allow scoping the resulting 20 users to only those eligible to an arbitrary approval rule - The latter option (scoping to an approval rule) is probably the better option, particularly if we can send a list of rules or simply indicate "all of the rules for this MR." - The reason for this is essentially that 20 users may not be sufficient to include all of the top suggestions for each approval rule in the `Assign` sidebar panel. If each dropdown can request their own customized list of top matches based on what approval rule they're showing, we can provide the best results. - The alternative (a longer list of users) is basically a hedged bet that the sorting algorithm will include approval rules as a high-ranking weight, so when we filter a longer list to only those eligible for a rule, we'd get enough to populate each dropdown. - Have a single "get reviewers" 'pipeline' that the MR page uses to hydrate all of the dropdowns that performs each necessary step: fetch, sort, filter. ### Outcomes - gitlab~2492649 `PATCH` for MR reviewers: - `{ "add": [ "x", "y" ], "remove": [ "z" ] }` - gitlab~2492649 new Reviewers endpoint: - `/merge_requests/:id/advanced_reviewers?approval_rules=1234,5678,9012` - gitlab~3412464 refactor to use single "path" through the code for reviewers list (with sorting/filtering) - gitlab~3412464 update to use new endpoint - gitlab~3412464 update to use per-dropdown `PATCH` instead of a global collection that fully replaces the whole list