Skip to content

Frontend Venues

Venue company profiles expose organization invitations, Auth catalog-backed module/general permissions, read-only Core business-unit structure, and Auth business-unit assignments through the Venue BFF. Finance workflow roles are not editable here — Submitter/Approver, approval limits, primary approver, and Primary Finance Admin are managed inside Finance.

The panel is access-only: there is no create, rename, or archive control for business units, and the page is hard-scoped to the user’s active company (page.tsx returns notFound() for any other company id). Granting Finance access assigns the user at Submitter level.

See the Company Access Ownership Matrix for the canonical split.

Related documentation: Venue Module Backend · Venue Module Backend API · Data ownership

Frontend-Kisum-Venues is implemented.

The repo TODO marks Phases 1–10 as shipped.

This is the venue-operator CRM at venues.kisum.io.

It is not a public venue browser and not an admin control-plane app.

  • Next.js 16 + React 19 App Router app
  • shared Auth bootstrap
  • venue module gating
  • app-shell no-venue gate with provisioning flow under Settings -> Venue
  • centralized space-scope handling
  • Kisum design-system operator pass: exact root body shell class, white main work area, canonical PageMainSection / PageSectionHeader page chrome, and compact workflow KPI strips on the main Venue CRM pages
  • Promoters shell mirror (2026-07-24): flat sidebar DOM + k-appbar header aligned with Frontend-Kisum-Promoters — global section search (⌘K), theme toggle, header primary-action store, Sonner toasts, NextTopLoader. Venues-only pieces unchanged: ScopeProvider, space switcher in the sidebar middle block, VENUE_MENU / hasVenueModule / hasVenue gates, PeopleMessagesUnreadProvider, wrong-package-screen, server bootstrap in @main/layout.
  • venue settings editor
  • spaces CRUD
  • space detail pages with operational profile, structured capacity/setup/pricing/technical/media/floorplan/marketplace fields, booking-slot summaries, and from-price from default package indicative rent
  • commercial package templates (/settings/commercial/templates) and per-slot packages (/settings/spaces/[spaceId]/slots/[slotId]/packages) with structured term builder (base rent, F&B %, ticket %, versus groups)
  • booking detail slot package snapshot card (frozen terms + drift warning) and post-event settlement card (manual sales inputs → calculated rent → Finance submit)
  • calendar + availability blocks CRUD
  • bookings list, detail, create, status transitions
  • customer overlays and consolidated customer profile
  • deals list/detail/create/edit
  • contracts list/detail/create/edit/generate/send/resend/status refresh
  • deposits create/edit
  • booking finance-status card
  • events list/detail/create/edit/link-promoter
  • operations checklist list/detail/create/edit
  • operations templates list/detail/create/edit
  • reports overview + utilization/revenue/profitability/customers

Representative live route families:

  • /dashboard
  • /calendar
  • /bookings
  • /bookings/[id]
  • /events
  • /events/[id]
  • /customers
  • /customers/[id]
  • /deals
  • /deals/[id]
  • /contracts
  • /contracts/[id]
  • /deposits
  • /operations
  • /operations/[id]
  • /operations/templates
  • /operations/templates/[id]
  • /reports
  • /reports/utilization
  • /reports/revenue
  • /reports/profitability
  • /reports/customers
  • /settings/venue
  • /settings/spaces
  • /settings/spaces/[id]
  • /settings/commercial/templates
  • /settings/spaces/[spaceId]/slots/[slotId]/packages

These should stay marked as pending:

  • PATCH /api/v1/customers/:id/overlays/:overlayId backed in-place overlay editing
  • real Adobe Sign upstream instead of adapter-backed send/resend flow
  • deeper Finance obligation/settlement ownership beyond the current Venue-side visibility and deposit sync contract
  • desktop/mobile visual regression screenshots for the normalized Venue frontend
  • equivalent design-system polish on the promoter venue marketplace pages in Frontend-Kisum-Promoters
  • managed upload/library UX for venue and space imagery/floorplans
  • venue/space edit audit trail UI
  • venue create/delete stays in Admin, not here
  • Finance truth stays in Finance
  • canonical shared-party master data stays outside this frontend
  • canonical promoter event truth stays in the Promoter module; Venue links or creates placeholders

Older docs that say contracts, deposits, operations, reports, or events are still future-only are stale.