Fix manual Status Update runs with multiple candidate integration configs.
Review Request #12835 — Created Feb. 21, 2023 and submitted
When performing a manual run of a
StatusUpdate, the code responding to
the manual run signal had no choice but to try to find a matching
IntegrationConfigfor the review request. If multiple matches were
found, it had to pick one, and this could easily be the wrong one.
To solve this, we now store the configuration ID in
StatusUpdate.extra_data, using a private key. This is stored either
when setting the new
StatusUpdate.integration_configproperty, or when
StatusUpdate.objects.create_for_integration()(which is the preferred
way going forward).
When either setting or fetching the configuration, the configuration is
validated to make sure it matches the same
LocalSite, to avoid any
cross-site contamination issues.
status_update_request_runsignal is now given a
mapping to this stored configuration (if one is stored), which
integrations can use. This will require a change for integrations
handling that signal to prioritize the new argument.
Old Status Updates in manual run mode will result in a
configuration, which will need to be handled through legacy means, but
all future Status Updates created after this change will have a suitable
All unit tests pass.
Tested this along with changes in rbintegrations to make use of the
This will be tested in production with an affected customer.
Removed unused imports.
Revision 2 (+1268 -4)