TMSS-917: primary subtask
It proved quite difficult to have the "constraint" of only one primary subtask per parent task_blueprint.
In order to achieve that I had to rewrite TMSS-568 such that the parallel calibrator and target LBA subtask are now in one single parent TaskBlueprint, but defined in two subsections in the json schema. That rewrite was much bigger than the "primary" subtask stuff.
Reintroduced the not-null constraint on the parent TaskBlueprint for the Subtask.
Also had to adapt many tests for the new restrictions.
All in all, we now have a much more strict but usable model.
Closes TMSS-917
Merge request reports
Activity
added 4 commits
- 5f324d14 - TMSS-917: no definitions referenced_schema, make empty default
- 35262aa3 - TMSS-917: raise more specific json decode error
- 4c72a475 - TMSS-917: refactored the parallel LBA calibrator and target observations into...
- 877de1a3 - TMSS-917: reverted to a single parent TaskBlueprint for a Subtask.
Toggle commit listadded 1 commit
added 1 commit
added 1 commit
added 1 commit
added 1 commit
added 1 commit
added 83 commits
-
7ecb974f...7c5d4899 - 82 commits from branch
master
- efd221a5 - Merge branch 'master' into TMSS-917
-
7ecb974f...7c5d4899 - 82 commits from branch
added 1 commit
added 1 commit
added 2 commits
Would we break the front-end with this merge?
I don't think so. The frontend hardly uses subtasks, and it's the subtask reference to its parent task_blueprint that changed from ManyToMany to a plain ForeighnKey. I scanned the frontend code for occurrences of the property 'task_blueprints' but it's only used on scheduling_unit_blueprint instances, never on subtasks.
mentioned in commit 94ecce36