Skip to content

fix enum/array config property rendering, block edit during pre-event window - #240

Merged
jencompgeek merged 4 commits into
mainfrom
jh/feat-properties
Nov 10, 2026
Merged

jencompgeek merged 4 commits into
mainfrom
jh/feat-properties

Conversation

@jencompgeek

@jencompgeek jencompgeek commented Nov 6, 2026 •

Copy link
Copy Markdown
Collaborator

What is in this PR?

Two fixes to support new pregame feature bundled together from recent event-creation/admin work:

  1. Feature config properties in EventCreationForm — enum radio buttons with no validationKeys (e.g.
    plain { value, label } options) silently did nothing when clicked, and an explicit default on
    such a property never pre-selected a radio either. Also adds rendering for the new array config
    property type.
  2. Admin events list — the Edit button was clickable for a confirmed event sitting inside its
    pre-event window, even though editing an active event is already blocked. Closes that gap.

Changes in the codebase

  • components/EventCreationForm.tsx: added getEnumIdentity/serializeEnumIdentity helpers that resolve
    an enum option's comparable identity consistently — via validationKeys when set, via a { value,
    label } option's value otherwise, or the raw value as a last resort — and use them for rendering,
    defaulting, and submission. Previously the RadioGroup's controlled value and each option's value
    could be serialized inconsistently, so no option ever compared equal and nothing visually
    selected; an explicit default also bypassed validationKeys extraction entirely.
  • components/EventCreationForm.tsx: added a case 'array': to the dynamic property renderer. Since
    array-type properties (new in ConfigProperty.type) have no fixed option set, they're edited as
    free-form comma-separated text and parsed into a trimmed, non-empty string array at submission via
    a new parseArrayPropertyValue helper.
  • openapi.json: synced to add "array" to ConfigProperty.type's enum (no other fields were added
    alongside it — array properties reuse the existing default/options fields as plain
    comma-separated/joined values rather than structured items).
  • pages/admin/events.tsx: canEdit now also excludes an event inside its pre-event window via the
    existing isInPreEventWindow helper (already used by the chat flow for the same window), since that
    window leaves active: false and startTime unset.

Documentation and automated testing

Did you:

  • document any breaking changes in your commit messages?
  • document your changes as comments in the code? Use TSDoc format where appropriate.
  • update the README and docs to be clear and easy to use for end users and developers?
  • add and/or update automated tests?
  • update team documentation of any new or changed environment variables?
  • If openapi.json changed: names the llm_engine PR/commit it came from, and whether that backend change is deployed
  • add a What's New entry in content/whatsNew.ts for new features?

Testing this PR

Test in conjunction with BE PR berkmancenter/llm_engine#436

  • In Step 3 of event creation, ensure Warm Up Format radio buttons of Pregame feature render correctly and are selectable
  • Confirm Pregame Warm Up Question Options renders as a plain text field; type
    comma-separated values, submit, and confirm the payload contains a trimmed array (e.g. "a, b ,, c"
    → ["a", "b", "c"]).
  • On the admin events list, confirm the Edit menu item is hidden for an event currently inside
    its pre-event window (active: false, scheduled time within preEventMinutes of now), same as it's
    hidden for an active event.

Additional information

@vercel

vercel Bot commented Nov 6, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
nextspace Ready Ready Preview Nov 10, 2026 5:00pm UTC

Request Review

…tionKeys

getEnumIdentity returned {} for a primitive option/default whenever
validationKeys was set, since it only ever read keys off an object.
openapi.json's ConfigProperty.default permits a bare primitive even
when options are object-shaped, so a schema-legal primitive default
never matched any radio option's own identity and nothing pre-selected
on load. Map a primitive straight to its single validation key's
value; ambiguous multi-key cases are left as before.
…ate siblings

canEdit was an inline boolean expression that had accreted conditions
across several separate edits (an isOwner check added then removed,
a type check added, a pre-event-window check added), unlike
deriveEventState/isInPreEventWindow/isEventMissed, which name, document,
and centralize the same kind of lifecycle question. Give it the same
treatment so a future edge case has one tested place to land.
@jencompgeek
jencompgeek merged commit 33d1a26 into main Nov 10, 2026
3 checks passed

This branch was successfully deployed

1 active deployment
Preview — b2bc2c7b Deployed Nov 10, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant