Pools are an extension of groups, not a replacement.

A key benefit of groups is that they live at the office level, which means that they can apply across multiple schedules easily and be used on office roles. However, it’s not perfect for every scenario.

Pools would live at the schedule level. They can be used with or without groups, so a pool may belong to a single group, or may be used without a group. Pools would behave as a subset of groups, and provide most of the same functions, namely segregating teams and providing multiple standings within a schedule as groups already do.

The drawback of pools is that they cannot be used for authorization, as groups can be. This means when creating an office role, you would not be able to limit a permission to a pool. However, you would continue to be able to limit permissions to a group, which may limit the pools they have access to, based on the group relation.

Example

PCAHA playoffs provide an interesting example of how pools would be beneficial. They create a schedule per category, such as “U13A Playoffs”.

Playoffs are by team tier, but they also have multiple series within the tier, so they end up creating numerous groups such as “Tier 1 - 1st Round”, “Tier 1 - 4 Points Series”, “Tier 1 - Final 4” and they repeat this for all 4 tiers. A league manager is responsible for each tier, so they have to be added to each group.

It’s not possible to create groups for just “1st Round”, “4 Point Series” and “Final 4” and then create schedules for each tier because a different league manager is responsible for each tier, so there would be no way this would allow authorization filtering, and also there are “President Series 1-n” groups for eliminated teams that span all tiers.

With pools, the league would just create groups for each tier, to allow for reduced authorization filtering, and then create pools for each group in the schedule. This would not effectively change how standings work.

Requirements

• Create many pools at once within a schedule

• Pools maintain all the same functionality as groups, except authorization and notifications. Anywhere there’s a groupId, a poolId should be added.

Models

Pool

Pools are associated to a schedule and may be used with or without a group from the schedule’s office. Unlike groups, they don’t need a schedule type, season or category, since the schedule already denotes those properties.

Group

Add displayOrder to groups since sorting by name can provide undesired results. Not necessary for pools, just a nice UX enhancement.

Game, DraftGame, ScheduleTeam, ScheduleSequence, TeamScheduleStats, ParticipantScheduleStats

Add poolId to these models.

In games, when a pool is selected, the teams are filtered based on the ScheduleTeams like group, so teams must be in the selected pool.

When generating a game number, a matching sequence with the same poolId should be used, otherwise the matching groupId if it has no poolId, or sequence with no groupId and poolId.

Stats are grouped per groupId and poolId.

Implementation

• Add pools to game, draft game, schedule teams

  • Game team validation must require the team to be in the pool if a pool is specified

• Add pools to sequences

  • Generating a game number comes from the pool first, otherwise group, otherwise schedule

• Add pools to stats

  • Same logic as groups, but pools create an additional level of segmentation

• Pools UX

  • In a form, show the pools input under the group input, and like the group input, it only shows if there are any pools

  • Display pools together with groups. If there’s a group and pool show “Group - Pool”, otherwise just show the group name or pool name if only one is selected

  • When filtering pools, they show as individual inputs. This allows showing all pools related to a group at once if desired.

• Pools do not affect authorization or notification filtering at all

• Page and Play websites will also need to be updated, along with notifications.