MM TicketOps · Documentation Hub

Every flow, every screen, every data field — mapped.

Four lenses on the same system. Start with the Journey to see how everything connects. Drill into Mocks for per-screen detail. Use Flows as the exhaustive reference. Use Screens to plan build order.

19Primary flow sections
72Screens documented
249Excel columns mapped
34Clickable journey blocks
J

User Journey — clickable block diagram

JOURNEY.html

The full journey as a visual block diagram: 8 phases, 34 clickable blocks, from event setup all the way to archive. Each block opens a detail modal with form mock, FIFA + Olympics scenarios, data writes, side effects. Start here.

Open the journey
M

Form & Screen Mocks

MOCKS.html

Side-by-side FIFA vs Olympics mocks for every critical screen — Create Event · Schedule upload · New Sale (revised) · Client Portal · Supplier Portal · and more. See how one component adapts.

  • Sale form with revised field order (Match moves into lines)
  • Client Portal with filter bar + Accept Receipt
  • Supplier Portal with MIRRA redaction
  • Seat map upload + category paint
View mocks
S

Screen Catalog

SCREENS.html

Every screen in the app, categorised by frequency. Tabs filter by Main operation (17), One-time setup (16), Rare / modification (39). Useful for build planning + role mapping.

  • Main = daily-use screens for staff/operators/clients
  • Setup = config screens per event / venue / org
  • Rare = exception-path (audit · override · cancel)
Browse screens
F

Complete Flows Reference

FLOWS.html

The exhaustive reference. 1,293 lines. 17+ sections covering every workflow, every entity, every column of both Excel workbooks (FIFA + Olympics) — 100% coverage verified programmatically.

  • §0–§14 — phase-by-phase flows
  • §15 — actor × flow matrix
  • §16b — full column manifest + autofilters + freeze panes + conditional formatting
  • §18 — Olympics data model
  • §19 — Implementation rules · hardcoded infra · admin ops · regexes · error strings
Open flows
R

Requirements & Gap Analysis

REQUIREMENTS.md

The product document. Maps spec → v1 app → v2 app. Flags 9 bugs already in the code, 14 open product decisions, prioritised P0/P1/P2 action list. 654 lines of "what to build, what's broken, what's missing".

  • Field-by-field entity gap table
  • Full Apps Script ground-truth (29 files audited)
  • Hidden business rules surfaced (Matthias · MIRRA redact · single-checkbox guard)
Read the requirements

Source evidence · grounded in everything in the repo

Every claim in these docs is traceable to a source file. Zero speculation.

□
3 PDFs · 14 pagesMM-DMCC flowchart · System summary · Screenshots workflow
▤
System FlowChart JPEG6-box top-down diagram
◈
Mirra-Management-TDS.htmlTechnical design spec
▦
Dummy - MM_Dist_sheet.xlsx18 sheets · 106,285 rows · 237 columns
▦
Olympics 2024.xlsx1 flat sheet · 3,220 rows · 12 columns
◆
29 Apps Script source filesThe actual production backend (~363 KB)
▣
4 walkthrough screenshotsNew Sale form · Command Center · Client sheet · Supplier sheet
⬡
mm-ticketops/v1 React app · audited in full
⬡
mm-ticketops-updated/v2 React app (in progress) · audited

Key principles to remember when building

01

Distribution is the single source of truth

Everything flows through it. Client portals, staff queues, supplier queues all derive from Distribution. Never bypass.

02

Allocation works at the unit level

One ticket = one _PURCHASE_UNITS row = one child DistRow. Every field tracks down to that atomic unit.

03

Redaction by value-substitution, not by row-filter

Supplier workbooks always show Company = "MIRRA". Client company identity is never revealed — not even accidentally.

04

Placeholder teams are a first-class citizen

Bracket matches like "Winner QF1" must accept sales before the teams are known. Cascade resolution when results arrive.

05

One client can span many matches in one sale

Match field moves into each line item — agencies frequently buy across the whole tournament in one invoice.

06

Every allocation mutation is append-only audited

_ALLOC_LOG records ALLOCATE · UNDO · override · password-reveal · credential-change · event-transition. Never overwrite.

07

Filters over volume

Large clients manage thousands of tickets. Portal must filter by match / category / delivery / block-row / holder — otherwise the table is unusable.

08

Client Accept closes the loop

ACCEPTED is the terminal dispatch state. Client acknowledges receipt — cascade back through Distribution and Supplier.

09

Olympics vs FIFA share the same pipeline

Same purchase → units → sale → allocate → dispatch flow. Just different identifier schemes (P-prefix units, M-prefix or sport-prefix matches).