SPR-706 Assignment Settings
- Edouard Larouche
- Tomi Mitrovic
- Gilles Taillon
This is to cover managing settings on a per-game or per-assignment basis, which would either have been generated by the system or managed by the user.
Note that the office configuration of these rules is out of scope and covered in separate epic document.
Requirements
League sets assigner determination. Assigners would have access to their games even if they’re onboarded late
Assigners can add any amount of positions arbitrarily (not limited to systems) and use any custom created position (Referee 1, Referee 2, Scorekeeper Supervisor, Video Official, etc)
Delegation is a first-class feature, not an after-thought. Primary assigner remains assigned to the game and is able to delegate and redelegate positions as they need.
Base fees for an official can be independently set of other officials
Models
AssignRule
Deprecated - Out of scope for this epic
AssignSystem
Deprecated - Out of scope for this epic
AssignFee (Pay Structure)
Deprecated - Out of scope for this epic
GameAssignSettings
All other properties deprecated as they’re moved onto GameOfficialSettings
Property | Type | Description |
|---|---|---|
gameId | id |
|
officeId | id | Primary assigner. This is based on assigner determination settings. |
GameOfficial
Two properties deprecated: officeId, feesId
GameOfficialSettings (or GameAssignment?)
Property | Type | Description |
|---|---|---|
id | uuid | Currently the API generates a random UUID when a position is unassigned, so this would take place of that when assigning an official. This id will be a relation to the GameOfficial id. This behaviour will also be super convenient for migration. |
gameId | id |
|
officeId | id | Office responsible for assigning the position When a game is delegated, the office of the GameAssignSettings will retain access to all assignments, but the delegated assigner will gain the ability to assign the game and the list of officials will be based on this office. |
positionId | id | OfficialPosition |
minLevel | number | Optional |
minGrade | number | Optional This may become deprecated if we move forward on attribute requirements. |
minAge | number | Optional |
amount | decimal | Optional This would’ve previously been an assign fee ID, but it makes more sense to just have a direct amount on the official settings to limit complexity. |
status | enum | Active | Draft |
Implementation
When the game is (re-)scheduled and settings are produced, rather than creating one set of settings per game, create settings for each expected official. A separate epic describes how settings are produced which deprecates related models noted above.
Official settings
This approach balances a delicate split between what belongs (and is constrained by) the scoresheet and not. We’ve found that managing the delegated office (and it’s fees) in the game official has been a pain. If we continued this approach, the settings changes would need to be managed by the scoresheet reducer.
Since we already randomize IDs for game officials when they’re not assigned, it’s very convenient to just produce GameOfficialSettings with IDs that could be reused for the eventual GameOfficial once the game is assigned. This also provides stability between the scoresheet and respective official settings so we don’t have to worry about keeping a set of IDs in sync with each other as changes occur.
Position requirements
Previously GameAssignSettings had to manage requirements (level, grade, age) for all officials, but given the naming of the properties (minRefereeLevel) this would break as soon as we introduce custom position types. Therefore having a GameOfficialSettings per official avoids that issue entirely.
This also provides a lot of new flexibility to modify the requirements per assignment. If an assigner wanted to increase the base rate for one official they would be able to do so (although this is moot with transaction types).
Primary and delegated assigner
When resolving assigner determination, GameAssignSettings are created with the officeId, which indicates the main assigner responsible for the game. Once that is set, the requirements determination is resolved to create GameOfficialSettings for each required position, and the officeId of those default to the main assigner.
Delegation is moved out of scoresheet into the GameOfficialSettings model, which the main assigner can change at any time, or the delegated office can change for their official (and would lose access immediately afterwards).
Officials available to the assigner (and games available to the official) are based on the GameOfficialSettings only. Transactions use this office as well by default, unless a new setting is activated to be paid by the main assigner.