Currently we expect there to be at most one decision linked a job, so if another decision occurs from an override we overwrite the existing ContentDecision instance. Aside from losing information about the previous decision (which is retained in the activity log at least), we then can't tell from the model states if a decision was overridden - a problem because we need to know if we should send different email content.
The main thing that makes this a hard change to make is the one-to-one fk is on CinderJob, and for a many-to-one from ContentDecision to CinderJob it needs to be on ContentDecision - and that means a lot of tests need updating 😐
Acceptance Criteria
### Milestones/checkpoints
- [ ] A sentence describing the first milestone/checkpoint
Checks
[X] If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"
Description
Currently we expect there to be at most one decision linked a job, so if another decision occurs from an override we overwrite the existing
ContentDecisioninstance. Aside from losing information about the previous decision (which is retained in the activity log at least), we then can't tell from the model states if a decision was overridden - a problem because we need to know if we should send different email content.The main thing that makes this a hard change to make is the one-to-one fk is on CinderJob, and for a many-to-one from ContentDecision to CinderJob it needs to be on ContentDecision - and that means a lot of tests need updating 😐
Acceptance Criteria
Checks
┆Issue is synchronized with this Jira Task