Refactor registrations create around success and failure paths
What does this MR do and why?
Refactor registrations create around success and failure paths
- no behavior changes
- changed ordering so that we didn't imply an order that wasn't needed around call of
super
in theafter
hook.
- changed ordering so that we didn't imply an order that wasn't needed around call of
- noticed during implementation of !146548 (merged) that we had a repeating pattern emerging in the create action that pointed to a distinct success path. So instead of adding to that pattern, instead focus here on enhancing readability and clarity around these paths and leverage the after success hook to increase clarity in this area.
- refactored some actions so that they were placed behind individual methods and removed unneeded overrides in
ee
where possible
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #435745 (closed)