Fix manual Status Update runs with multiple candidate integration configs.

Review Request #12835 — Created Feb. 21, 2023 and submitted — Latest diff uploaded

Information

Review Board
release-5.0.x

Reviewers

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
IntegrationConfig for 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_config property, or when
creating the StatusUpdate using
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.

The status_update_request_run signal is now given a config argument
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 None
configuration, which will need to be handled through legacy means, but
all future Status Updates created after this change will have a suitable
configuration.

All unit tests pass.

Tested this along with changes in rbintegrations to make use of the
new config state.

This will be tested in production with an affected customer.

Commits

Files