[Open311] Generally store update state.

Previously, an update's problem_state was set via an Open311 update if:
* the update timestamp was equal or greater to the report's last update;
* the new state was visible, and not equal to the report's current state;
* the update wouldn't change the report from a fixed state to another fixed state;
* (Oxfordshire) the update wouldn't change the report from any open state to Open.

It would also set the report's state to match if the report was currently visible.

This mostly worked, but could lead to issues if e.g. the report started life in
a non-confirmed state (e.g. we pulled it in already fixed from an external
source), as then the update did not record its state and the update display got
confused as to the state history. However it did mean there wasn't confusion if
a later update than the Open311 update was made on the site itself.

This new code will set an update's problem_state if:
* the new state is visible;
* the update wouldn't change the report from a fixed state to another fixed state;
* (Oxfordshire) the update wouldn't change the report from any open state to Open.

It will also set the report's state to match if the report is currently
visible, changing state, and the update timestamp is equal or greater to the
report's last update.

So when the report state changes is unchanged, all the conditions still apply,
but the update's problem_state is set more often (it will be set regardless of
whether the timestamps align, or whether the state matches the report's current
state).

This could theoretically lead to issues elsewhere, e.g. if an update is left on
a report on FixMyStreet and then an Open311 update is pulled in later (but with
an earlier timestamp) that changes the state, the report state will not be
updated due to the later update being made, though the Open311 update will list
the state change, and then the later update might say it changed it back (if it
recorded the current state in its problem_state), even though it technically
did not. I think this issue is less worrying than the current situation, which
can state that a random update has fixed a report when it was the previous
update that did, and there will always be such issues with multiple sources of
truth for a report status. An alternative would be to allow the Open311 update
to override.

1 files changed, 1 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 50a3f18de..cdf048a9e 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -34,6 +34,7 @@
         - Set a session timezone in case database server is set differently.
         - Fix SQL error on update edit admin page in cobrands. #2049
         - Improve chart display in old IE versions. #2005
+        - Improve handling of Open311 state changes. #2069
     - Admin improvements:
         - Inspectors can set non_public status of reports. #1992
         - Default start date is shown on the dashboard.