Ir al contenido principal
Petanque Life

Umbrella & Design System (PL-T184)

F22.00 9 funcionalidades

En resumen

Foundation layer for the entire chain-venue platform. A per-tenant ChainVenueProfile document holds operational configuration in one place — opening rules, booking knobs, payment toggles — and a typed booking-color token system gives every booking type a consistent visual identity across calendar, floorplan, customer CMS and operator console, with WCAG AA enforced in CI.

Cómo funciona

When a CHAIN tenant onboards, the platform seeds a single ChainVenueProfile document keyed to the tenant. This profile is the authoritative source for opening rules, booking-engine knobs, payment toggles, smart-upsell rules, marketing automation, and any other knobs the operator can tune. Loading the profile is a single Mongo read with no joins, so console screens and storefronts stay snappy even on tablet hardware behind the bar.

The profile is fetched via GET /chain/venue-profile and mutated via PUT /chain/venue-profile — both admin-gated. Every mutation is recorded in an audit trail so support can answer "who changed the cancellation window last Tuesday" without guesswork. The booking-color token system defines eight booking types (court_play, table_dining, event_corporate, event_private, event_drop_in, tournament, maintenance, staff_shift), each with three variants (chip, surface, border) and two modes (light, dark).

Tokens are emitted as CSS custom properties consumed by both the marketing site (www) and the tenant-CMS (web), and shared with admin via packages/shared. Two CI tools enforce quality at PR time: audit-booking-colors.mjs checks WCAG AA contrast across every token combination, and audit-booking-premium-criteria.mjs blocks regressions against the documented UX bar. The result is one config-shaped contract and one visual contract that every other subsystem in the chain-venue domain plugs into.

Capacidades clave

  • Single ChainVenueProfile document per tenant — authoritative operational config
  • Eight booking types × three variants × two modes color-token matrix
  • Admin-only profile read + write endpoints with full audit logging
  • Default seeding on CHAIN tenant onboarding — zero-config day-one launch
  • WCAG AA contrast audit enforced in CI
  • Booking premium-criteria CI gate prevents UX regressions
  • Shared CSS custom properties consumed by www + web + admin

En la práctica

A new boule-bar operator signs the chain-tier contract on Monday morning. The onboarding job provisions the tenant, seeds a ChainVenueProfile with sensible defaults, and the operator lands on the admin dashboard with everything wired up. They open Settings → Venue Profile, raise the cancellation window from 4 h to 24 h, flip dynamic_pricing_enabled on, and save.

The audit log records the change with their user_id and timestamp. By Friday, when district manager asks why peak-hour quotes look different, support pulls the audit trail and shows exactly when and by whom the toggle was flipped. Meanwhile, the booking calendar, floorplan, and customer-CMS all render bookings in the correct color-coded chips because every surface reads from the same shared token file.

Funcionalidades de este subsistema

9
ID Status Funcionalidades
F22.00.01 Entregado Booking color token system (8 types × 3 variants × 2 modes)
F22.00.02 Entregado CSS custom properties for www and web
F22.00.03 Entregado ChainVenueProfile Beanie model
F22.00.04 Entregado GET /chain/venue-profile (admin-only)
F22.00.05 Entregado PUT /chain/venue-profile (admin-only)
F22.00.06 Entregado Audit logging on all profile mutations
F22.00.07 Entregado Default seeding on CHAIN tenant onboarding
F22.00.08 Entregado WCAG AA audit tool (audit-booking-colors.mjs)
F22.00.09 Entregado Booking premium-criteria CI gate (audit-booking-premium-criteria.mjs)