Our theory for #907 is that previous versions of the code, applying less rigorous filtering for cases, added aggregation rows for which there is now no longer data with the more restrictive filtering.
Our aggregation code never removes or zeros out these orphan rows, leaving data in the KPI report that is incorrect.
This PR adds some extra logging to identify these rows. We can then manually delete or correct using the Django admin in order to produce the KPI report for #895.
The original commit from @eatyourpeas (25b23dec84fa8f2f84ff8b0b5917685ae8366b6e) set these rows to zero. I think it's better off to start by identifying them so that we can try to preserve at the aggregation level a distinction between organisations who have data but it is filtered out for aggregations and those organisations who have never entered data.
Our theory for #907 is that previous versions of the code, applying less rigorous filtering for cases, added aggregation rows for which there is now no longer data with the more restrictive filtering.
Our aggregation code never removes or zeros out these orphan rows, leaving data in the KPI report that is incorrect.
This PR adds some extra logging to identify these rows. We can then manually delete or correct using the Django admin in order to produce the KPI report for #895.
The original commit from @eatyourpeas (25b23dec84fa8f2f84ff8b0b5917685ae8366b6e) set these rows to zero. I think it's better off to start by identifying them so that we can try to preserve at the aggregation level a distinction between organisations who have data but it is filtered out for aggregations and those organisations who have never entered data.