Guest Access: Restructure Dashboard UI to Increase Usability

Overview & Context

Restructure the guest-access / waiting-room controls in the meeting create/update form. Replace the single "Waiting room" switch + "Guest access" selector with a clearer two-control combo: a top-level Guest access switch and a Waiting room toggle group (Inactive / For all participants / For guests only). The underlying form fields (waitingRoom: boolean, guestAccess: GuestAccess) stay unchanged

Technical Design & Interfaces

Mapping table (UI → API):

Waiting room (UI) Guest access (UI) waitingRoom guestAccess
Inactive off false Disabled
Inactive on false DirectAccess
For all off true Disabled
For all on true WaitingRoom
For guests only on false WaitingRoom
For guests only off n/a - toggle option disabled

Frontend & UI Requirements

Translations

Key English German
dashboard-meeting-waiting-room-switch (reused as toggle group label) Waiting room Warteraum
guest-access-switch-label (reused as switch label) Guest access Gastzugang
dashboard-meeting-waiting-room-option-disabled Inactive Inaktiv
dashboard-meeting-waiting-room-option-all-participants For all participants Für alle Teilnehmer
dashboard-meeting-waiting-room-option-guests-only For guests only Nur für Gäste

Implementation Notes

  • Keep the API contract untouched
  • "Guests-only" without guest access is structurally impossible

Implementation Tasks

  • Refactor GuestAccessSelect to render the Guest access switch + Waiting room toggle group, driven by the mapping helpers
  • Add the three new translation keys in en/k3k.ftl and de/k3k.ftl.
  • Unit tests for deriveUiState, computeFormValues, and the round-trip in guestAccessMapping.test.ts.

Definition of Done (DoD)

  • No regressions caused to the meeting create/update API payload - saved events round-trip identically for all UI states.
  • Add unit tests (mapping + round-trip)