[E03] Event Setup
Summary
Use-case spec to be authored. See Claude Design ⇄ Claude Code Workflow § Use-case page structure for the format, or copy partials/use-case-template.adoc and fill in.
Notes
|
CSA event id. This screen is the intended home for the event’s CSA event identifier, which CSA requires when a day licence is issued at the federation. An event’s day-licence issuance stays inert until the identifier is set, while riders are still billed the day-licence product either way — so an event configured with a day-licence product but no identifier accumulates riders who have paid for a licence that only an administrator can issue by hand. The screen should therefore make the identifier visible and editable, and make its absence obvious on an event that bills a day licence. Until this screen exists, the identifier can only be set over the REST API, which puts event configuration out of reach of the customers who run the events. The same applies to the event’s other CSA settings — membership required, licence required, strict registration, day-licence disallowed — and to the day-licence product slot. All are editable on the entity and on the API, and none has a portal surface. |
|
Event contact details. The event carries three public-contact fields, What they control: they are the organiser contact that customer-facing messages print for the event. The notice sent when a participant’s race number is taken out of service lists each upcoming event with an "Event contact" line built from these fields, and omits the line when they are blank, so the message falls back to "reply to this email". Any future event email that names a contact (entry confirmation, cut-off notice) is expected to read the same fields, and the Configure an Event procedure lists them as the event’s public contact. They do not affect the sender or reply-to address, which is the environment’s mail configuration, and they do not affect registration or results. Until this screen exists, the fields can only be set over the REST API. |