[Kennyando]

Why

The short-notice booking warning added in #163 was hardcoded: every venue warned at 7 days with the same fixed text, and changing either meant a code change and redeploy. Venues have different lead times (e.g. MPSH needs ~2 weeks to arrange equipment and staff, while a seminar room needs less), and some venues don't need the warning at all.

This PR lets admins configure the warning per venue from the existing Venue Update page.

What changed

Admin (Admin → Venues → Edit)

• New Short Notice Warning section in the venue form, between Venue Details and Custom Booking Form Fields:
  • on/off toggle (fields hide when off; values are kept)
  • "Warn when booking is within (days)" (1–365)
  • warning title and message (plain text; line breaks kept, links clickable)
  • Preview as user button that opens the exact popup users will see
• All Venues cards show a tag: "Warns within N days" or "No short notice warning".

Users (booking creation)

• The popup now uses the selected venue's settings: no popup if the venue has it off, otherwise that venue's days, title and message.

Backend

• Venue gets 4 fields: short_notice_enabled, short_notice_days, short_notice_title, short_notice_message (migration 0018).
• Returned by venue_to_json(full_details=True); accepted by POST /venues/ and PUT /venues/:id through VenueSerializer.
• The fields are optional in requests; omitting them leaves a venue's settings unchanged, and new venues get the defaults.

Approach and alternatives

• Per-venue columns on Venue rather than a separate settings table. We considered an org-level BookingSettings model with per-venue overrides, but each venue only ever needs one set of settings, and per-venue columns reuse the existing venue API, form and fetches (the booking page already loads full venue details), with no new model or endpoint. Org-wide defaults can be added later on top of this without breaking anything.
• Plain-text message with no {days} placeholder. We prototyped a templated message, then dropped it for simplicity. The default message deliberately contains no number, so it can't drift out of sync with the days setting.

Where to look

• Heart of the change: frontend/src/components/venue-details-form/venue-details-form.tsx. It holds the new section, the validation, and withValidShortNoticeSettings.
  • Validation only runs while the warning is enabled, so a hidden field can never block saving.
  • When the warning is off, any invalid or blank hidden value falls back to the venue's last saved value before submit, because the backend would still reject it.
• Backend: venues/views.py (get_short_notice_settings), venues/logic.py, venues/models.py.
• booking-creation-time-slot-selector.tsx: missing settings fall back to DEFAULT_SHORT_NOTICE_WARNING (on, 7 days). This keeps the warning on for booking drafts saved in localStorage before this deploys.

Testing

• Backend: added venues/tests.py, the backend's first tests (4 cases): defaults on create, partial update keeps the other settings, the serializer rejects 0 and 366 days, and omitted fields stay out of validated_data. All pass.
• Frontend: tsc --noEmit, ESLint and Prettier are clean.
• Manual (local Docker backend and Vite):
  • The migration applies cleanly, and existing venues show "Warns within 7 days".
  • Edited MPSH to 14 days with a custom title and a message containing a link. The preview matched, 0 days was rejected inline, and the save succeeded with the card updated.
  • Turned Flying Seed off: the fields hide, the save succeeds, and the card shows "No short notice warning".
  • Booking page: MPSH warned on a slot 10 days out with the custom text. Flying Seed showed no popup for a slot tomorrow.
  • Validation for hidden fields and the 255-character title limit were exercised locally after the last fixes.

Screenshots

1. Booking calendar: the blocked 12am–7am slots (from Feature/restricted-hours #164, unchanged here). The short-notice popup on this page now uses the venue's settings.
2. Venue Update: the new Short Notice Warning section.
3. "Preview as user" popup, showing the venue's custom title and message.

Risks and rollout

• Migration: venues.0018 adds 4 columns with defaults to the existing venue table. There's no new table and no data backfill beyond the defaults. On deploy, every venue is on at 7 days with the default message, which matches today's behaviour except for the wording.
• API: the change only adds fields; existing fields are unchanged. The hand-written response examples in the venues/views.py extend_schema blocks are not updated and don't show the new fields. They also already disagreed with the real responses before this PR (category and organization are shown as objects but are actually strings). This could be a follow-up.
• Booking drafts: a draft saved in localStorage keeps the venue settings it was started with, the same as the other venue details in a draft.
• The warning is advisory only. Nothing enforces a minimum notice period on the server.

[Shum-ster]

LGTM