This is to replace the advanced assigning rules system with something that is more straightforward to understand for the average assigner.

Assigner determination (i.e., who is assigning the game) and game/assignment level settings (i.e., the steps after rule determination) are out of scope of this epic.

Requirements

• Simplify onboarding and ease of use. It needs to be straightforward to get started by saying what official requirements are necessary for each category

• Improve bulk reapply settings process; split out assigner determination

Out of scope

• Assigner determination

• Pay?

Models

AssignSystem

Deprecated

AssignFee (Pay Structure)

Deprecated

OfficialPosition

Replacement for AssignSystem that defines each position with a custom name and links it to a qualification type so we know which officials are eligible.

OfficePositionSetting (TBD)

Replacement for AssignRule to define the expected positions and requirements for each category.

OfficePositionFeeSetting (TBD)

Replacement for AssignFees to define the applicable fees for each position. Directly links to the prior model

Implementation

Assigner determination

• Schedulers should be in control of determining the assigner when the schedule is created

  • This either means using the office/schedule settings pattern or making use of another office/schedule-based model

• Typically the assigner is based on the arena in hockey, or home team for soccer.

  • In soccer, sometimes it’s the home team region.

  • Tournaments are always assigned by the host association

  • Playoffs typically behave like tournaments and are assigned by a host association

    • PCAHA has a different assigner for each group within the playoff

  • PCAHA has a different assigned based on the category. U15C+ is assigned by zone assigners, only after September 5th. Female games are all assigned by a single zone.

Delegation

Still need a way to define how to automatically delegate assignments. While the primary assigner is determined by the league, the delegated assigner is determined by the primary assigner so this would go in a different model. Could probably just introduce a new model like DelegationRule that specifies the category, position and how to determine the delegated office.

Assignment settings

The cards for “Assign Systems”, “Pay Structures” and “Game Specifications” would be replaced by a settings card that lists each configured category that combines the separate configurations into one.

Positions

We ideally want to end up with a 1:1 relationship between the office settings and game settings.

If a U15A game should have a 3 Person System, then you would create a settings entity for each position to manually create that 3 Person System and define the minimum level/grade/age and pay as you create it. In the UI we would want to make these entities clearly grouped by category so it’s easy to understand.

Pay

Determining pay is potentially a little interesting because it’s the primary use case we have for variances (game length, time of day, weekday) and we now have a transactions system that this configuration ends up in.

There are a few options:

1. Set the amount directly on the position setting, and then create a new position (repeating position/level/etc) for each variance.
   
   Complication with this is knowing when to cancel out the base position settings and having the user not screw up this configuration
   
   

2. Create an additional model for pay related to the position setting with an additional pay entity per variance. Variances would be removed from position settings. The amount would still be treated as a base transaction so the most specific variance would cancel out the others.
   
   

3. Same as #2, but allow this new entity to assign a transaction type (Base or Bonus) and use variances to determine when bonuses apply.

Note that pay needs to be strongly linked to the position in the UI for whatever solution we end up with. The current UX is really confusing with having an assign system configured in one card and pay structures configured in another card, and no way of knowing if the end result will properly be aligned until you create a game.

In a modelling sense, it makes a lot of sense to separate the configuration into separate entities (options 2/3) but it’s potentially a bit more of a challenging UI to implement and potentially more difficult to tie everything together in the API. Not necessarily though.

Tournaments Assignments

A tournament should be able to have / create a list of official dedicated for its tournament.

Tournaments are not always assigned by the association and therefore someone (third-party) may join and assign this tournament. Associations had to “give” rights in the association to allow them to schedule this tournament.

Requirements / Needs

• All tournaments should have the tournament assign it. So the assigning office should start from the tournament and they may delegate, change it if needed.

• Officials needs to be able to add the tournament as “My organizations” to be able to be assigned on it.

• Tournament admins may need to do lists of officials because the same tournament may have different categories and you may want to separate them by experience, veterans, levels specifically for this tournament.

• Tournaments often pay themselves the officials with the tournament budget and not the association budget, therefore allowing the full assigning concept to tournaments will allow them to have pay periods and making it way easier.