...
Deprecated - Out of scope for this epic
GameAssignSettings
Deprecated
GameOfficial
Two properties deprecated: officeId, feesId
...
All other properties deprecated as they’re moved onto GameOfficialSettings
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
officeId | id | Primary assigner. This is based on assigner determination settings. |
delegatedOfficeId
id
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 | |
officeId | id | Office responsible for assigning the position When a game is delegated, the primary assigner will remain the assigner with continued rights to settingsoffice 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 the delegated assigner.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 |
...
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 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 GameAssignSettings to 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.
...
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.