Frontend Venues
Users & Access
Section titled “Users & Access”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
Runtime status
Section titled “Runtime status”Frontend-Kisum-Venues is implemented.
The repo TODO marks Phases 1–10 as shipped.
Purpose
Section titled “Purpose”This is the venue-operator CRM at venues.kisum.io.
It is not a public venue browser and not an admin control-plane app.
Implemented now
Section titled “Implemented now”Shell and gating
Section titled “Shell and gating”- Next.js 16 + React 19 App Router app
- shared Auth bootstrap
venuemodule 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/PageSectionHeaderpage chrome, and compact workflow KPI strips on the main Venue CRM pages - Promoters shell mirror (2026-07-24): flat sidebar DOM +
k-appbarheader aligned withFrontend-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/hasVenuegates,PeopleMessagesUnreadProvider,wrong-package-screen, server bootstrap in@main/layout.
Core operator surfaces
Section titled “Core operator surfaces”- 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
Current route model
Section titled “Current route model”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
Not implemented yet
Section titled “Not implemented yet”These should stay marked as pending:
PATCH /api/v1/customers/:id/overlays/:overlayIdbacked 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
Ownership rules
Section titled “Ownership rules”- 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
Documentation note
Section titled “Documentation note”Older docs that say contracts, deposits, operations, reports, or events are still future-only are stale.