Proposal emails, session cancellation, and richer event descriptions

A batch of updates landed over the last few weeks. Here’s a quick tour of the ones worth flagging.

Proposal decisions now email the submitter. When you accept, request a revision, or reject a proposal, the submitter automatically gets an email with the outcome and a link to the next step — the draft Session if accepted, the call page for revisions or rejections. Revision emails include the message you wrote inline, so no separate follow-up needed. There’s a “Notify the submitter by email” toggle on the review page if you’d rather deliver the news in person; it’s on by default.

Cancelling a Session is now a proper flow. From the Session edit page, you can cancel with an optional reason. That withdraws all active enrollments (both enrolled and waitlisted) and sends an email to the Participants and the assigned Host — each worded for their role — so nobody finds out by turning up. Cancelled Sessions become read-only with a banner and free up their room and time slot, so you can drop in a replacement. If a cancellation was premature, “Reactivate” returns the Session to draft — no roster restore, no second email — and you decide how to rebuild it from there. The Participant-cancellation counter isn’t affected by an Organizer-initiated cancellation; those are different things.

Sessions with a Host who has no valid ticket now get flagged. A Session can end up with a Host who doesn’t hold a valid ticket for the Event — usually because their ticket was cancelled after they were assigned, or because they were assigned automatically when their proposal was accepted. Previously the Sessions table would still show them while the edit page’s Host dropdown silently dropped them, which was confusing to say the least. Now the table flags the Host with a warning icon and a hover message, and the edit dropdown keeps them selectable so saving doesn’t accidentally overwrite the assignment. Publishing a Session with an invalid Host is still blocked — that safeguard hasn’t moved.

Event descriptions can now include a full Markdown body. Until now an Event had a single plain-text description, which made for a pretty flat public “About this event” section. Events now have two fields: a short plain-text summary — used as an intro under the title and everywhere a short blurb appears (cards, org listing, ticket page, social-media link previews, PDF tickets) — and a longer body written in Markdown that renders on the public Event page. Existing Events keep their descriptions unchanged; the new details field is optional. The short summary also picked up a soft 280-character cap with a live counter on the form, to keep it actually summary-shaped.

A few small polish items rode along on the same page: the sidebar now leads with a “When” row, formatted differently for single-day and multi-day Events and always shown in the Event’s own timezone; Pricing is now a normal row in the details list rather than a separate block below it, and free Events use the same “Pricing” heading paid ones do; and the free-Event button now reads “Get Tickets” instead of “Register for this Event”, matching the wording used elsewhere.

Oh, and also — discount codes work at checkout now. If you set up promotion codes in your own Stripe Dashboard, participants will see an “Add promotion code” field on the payment page during purchase. Nothing extra to configure inside the platform, and recorded ticket revenue reflects the discounted amount.