Background: Participant answers are aggregated after 90 days from first answer or when the event ends. For the latter scenario, we need to store whether the answers have been aggregated, so that we can quickly determine whether the aggregation report should be shown. One thing to consider is whether this new field should also distinguish the following scenarios:
- Aggregates available
Aggregates are available, but cannot be shown because there aren't enough answersThis should be left to the application instead; also, we might change the min number of answers in the future, and therefore we can't easily store the "not enough answers" thing into the DB. And finally, I believe this would per question, not per event.- Answers are available, but not aggregated yet
- The event has no answers
Acceptance criteria
- The DB schema is updated to store the information we need
- The new column is added in beta
- The new column is added in production
Checklist
Because the column doesn't have a default value, this is going to be a bit more complex than usual:
- Create the new column in the code with a default value (corresponding to "no answers"; this is fine because the feature isn't enabled anywhere)
- Create the column in beta (T341642)
- Wait for code to reach production. We might consider backporting to avoid waiting for 2 trains.
- Create the column in production (T341679)
- Add the column explicitly to all write queries in the code
- Drop the default value from the code
- Drop the default in beta (T341642)
- Wait for the changes above (column written explicitly and default dropped) to reach production
- Drop the default in production (T341871)