Resolve TMSS-696 "Su priorities"

Closes TMSS-696

assigned to @schaap

Code looks fine, no remarks.

I understand that the priorityqueuetype A/B comes from ILT requirements, and hence have to be honored to "guarantee" that all "important" schedunits in queue A go first. That's fine, although a bit contradictory to the idea of completely free dynamic scheduling using constraints and sky optimizations. I guess we'll leave the A/B queue concept in a cycle or two when everybody is accustomed to dynamic scheduling.

The priority_rank per scheduling unit indicates the same "fear" that a scheduling unit is not place "soon enough" in the schedule. My take on addressing this fear is simple: use the current constraints like 'schedule before date X' and your scheduling unit will be scheduled before date X. Trying to tweak the schedule with individual priorities per unit is a vary old fashioned way of trying to be in control, but it does not guarantee anything. It gives a false sense of control and will lead to lots of misunderstanding/miscommunication and frustration. I understand that the PO wants it anyway, so we'll leave it in, and probably take it out again in a cycle or two when everybody is accustomed to dynamic scheduling and realizes that prioritizing individual is not needed to fill the schedule "optimally".

To address these issues and to provide more confidence in reliable dynamic scheduling we've created ticket TMSS-721 to have a repeatable test where we can run multiple scenarios to "optimally fill the cycle".

added 1 commit

• 023d4461 - TMSS-696: added PriorityQueueType in populate_choices

Compare with previous version

enabled an automatic merge when the pipeline for 023d4461 succeeds

aborted the automatic merge because source branch was updated

added 1 commit

• 42f23832 - TMSS-696: added PriorityQueueType serializer, viewset, url

Compare with previous version

merged

mentioned in commit 5cd3258b