Event Slots System

Event slots define the role composition and capacity for each event. They control how signups are allocated and whether participants are confirmed or waitlisted.

Slot Structure

Each event can have zero or more slots. A slot represents a role-based position:

Field	Type	Description
id	UUID	Unique slot identifier
eventId	UUID	Parent event
roleKey	string	Role identifier (e.g. tank, heal)
maxCount	number	Maximum confirmed signups for role

Signup Modes

Events have a signupMode that determines how signups are processed:

enroll (default)

Participants are automatically confirmed if the slot has capacity, otherwise waitlisted.

flowchart LR
    A[Signup request] --> B{Check slot capacity}
    B -->|Space available| C[confirmed]
    B -->|Full| D[waitlist]

waitlist

All signups go to waitlist regardless of capacity. Officers manually promote to confirmed.

flowchart LR
    A[Signup request] --> B[waitlist]
    B -->|Officer promotes| C[confirmed]

Slot Capacity Logic

When a user signs up for a specific role:

1. Find the matching slot by roleKey
2. Count current confirmed + attended participations for that slot
3. If count < maxCount and signupMode is enroll → status = confirmed
4. Otherwise → status = waitlist

If no roleKey is specified, the first slot is used as default.

Role Keys

Role keys are free-form strings defined per event. Common patterns for WoW:

roleKey	Typical maxCount	Description
tank	2	Tanks
heal	4	Healers
melee	6	Melee DPS
ranged	8	Ranged DPS
flex	5	Any role

Role keys are not enforced against a global list — guilds define whatever keys make sense for their events.

Slot Replacement

When an event is updated with new slots (via UpdateEventDto):

1. All existing slots are deleted
2. New slots are created from the DTO
3. Existing participations retain their roleKey (even if the slot no longer exists)

This means slot changes don't automatically reassign or remove signups.

Events Without Slots

If an event has no slots configured, signup attempts will fail with a BadRequestException. Every event that accepts signups needs at least one slot.

Recurring Events

When creating recurring events, slots are duplicated per event instance. Each event in the series gets its own independent set of slots with the same configuration.

When updating future events in a series (UpdateRecurringSeriesFutureUseCase), slots are replaced independently per event — each future event gets fresh slots matching the DTO.