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
Custom positions (Referee 1, Referee 2, Scorekeeper Supervisor, Video Official)
Ability to change the set of positions for a game arbitrarily based on needs
Improve delegation support
Ability to simply change assign fees mid-season
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
Deprecated
GameOfficial
Two properties deprecated: officeId, feesId
GameOfficialSettings (or Assignment?)
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 | |
positionId | id | OfficialPosition |
officeId | id | Primary assigner. This is based on assigner determination settings. |
delegatedOfficeId | id | Delegated assigner; optional. When a game is delegated, the primary assigner will remain the assigner with continued rights to settings, but the delegated assigner will gain the ability to assign the game and the list of officials will be based on the delegated assigner. |
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).
Delegation
Delegation is moved out of scoresheet into the new official settings model.
With this approach we don’t have to compare two different models to figure out the position fee, and it’ll be easier to update the fee in bulk when necessary.
Primary Assigner 🚩
Notably there are two offices on the assignment settings. This is to allow a primary assigner to change the delegate and oversee that the assignment does actually get assigned instead of losing access to it.
This may trade one problem for another as a potential solution to solve the onboarding problem is no longer valid now that GameAssignSettings is deprecated since all of it’s properties are moved onto the GameOfficialSettings and would only leave the office property. This approach has a problem when there are no positions determined.
Keep the
GameAssignSettingsto manage the office and always be able to manage positions. This seems excessive unless we have additional game-level settings we could introduce. That could complicate things with office assign settings though.Make
positionIdoptional so that we can have a placeholder assignment to allow a primary assigner to settings. This seems hacky.