DailyXFormSubmissionCounter doesn't actually have a pre_delete signal, so the xform=NULL counter isn't getting updated when xforms are deleted. This made sense when it got deleted after 31 days, but now it's our primary way of figuring out submission data on the usage page.
This PR resolves that by making the DailyXFormSubmissionCounter function more like the MonthlyXFormSubmissionCounter:
Adding a user field
Adding unique constraints between user, date, and xform (or just the first two when xform=NULL)
Adding a pre_delete signal to update the null counter
A separate PR for kpi will handle updating the shadow model (ReadOnlyDailyXFormSubmissionCounter).
Notes
I tried to update any place where daily counters are created to include the user. Because this includes the populate_submission_counters management command, I reordered migrations so that the schema changes happen before that command is run.
Description
DailyXFormSubmissionCounter doesn't actually have a
pre_deletesignal, so the xform=NULL counter isn't getting updated when xforms are deleted. This made sense when it got deleted after 31 days, but now it's our primary way of figuring out submission data on the usage page.This PR resolves that by making the
DailyXFormSubmissionCounterfunction more like theMonthlyXFormSubmissionCounter:userfielduser,date, andxform(or just the first two when xform=NULL)pre_deletesignal to update the null counterA separate PR for kpi will handle updating the shadow model (
ReadOnlyDailyXFormSubmissionCounter).Notes
I tried to update any place where daily counters are created to include the user. Because this includes the
populate_submission_countersmanagement command, I reordered migrations so that the schema changes happen before that command is run.