Rearchitect Approval Rules
In an effort to solve the issue of changes to ApprovalProjectRules
not cascading to the associated, unmodified ApprovalMergeRequestRules
(#254958 (closed)) we came up with 2 different approaches:
- update AMRRs when the
ApprovalProjectRule
(APR) changes (Draft: !48511 (04060448)) - have AMRRs delegate to their related APR unless the AMRR is modified (Draft: !48511 (closed))
However, neither approach is really great - each has some subtle issues, in either performance or how much complicated metaprogramming we need to do in order to end up at the expected results. In the discussion on various options, @patrickbajao suggested a rearchitecting of approval rules might be the best long-term approach. !48511 (comment 477202833) outlines the proposal, but it boils down to changing it so that
Rather than having ApprovalProjectRules
acting as templates, we instead would add
ApprovalRule
-
ApprovalRulesProject
- join table associatingApprovalRule
to aProject
-
ApprovalRulesMergeRequest
- join table associatingApprovalRule
to aMergeRequest
Rather than having individual records then, we reference the parent rule through the relationship associating the ApprovalRule
and the MergeRequest
/Project
. When a user modifies a project-level ApprovalRule
, we've nothing to update, and the change automatically is applied to all open MRs. When a user creates a custom rule or changes an existing one within the context of a specific MergeRequest
, we create a new ApprovalRule
and associate it to the MergeRquest
(and "simply" disassociate any previously existing rules that are now "modified")
It's a very subtle twist on the delegation approach I was working towards, but removes the need for mass-updating, as well as the fancy logic I was having to add via potentially confusing meta-programming.