Event tickets activation and passes

Discovery, records or a decision?

• Public events filter active resource events, without schedule/status checks. Public tickets filter active/nonprivate definitions; available is a current count, not reservation.
• Owned events differ from owned/assigned ticket groups. Empty ticket groups can be {}.
• Event passes are not caller-private: they expose base passes for that event/resource without owner/assignee restriction. Pass detail instead requires owner ID and does not independently enforce pass-resource association.
• Event access requires current user assignment to an active selected-resource event. HTTP 403 ti_events_access:false is an ordinary denial. It does not check every schedule/pass-state condition or authorize an article.

flowchart TD
    N[Choose intended task] --> D[Discover event and ticket definitions]
    N --> R[Inspect existing pass records]
    N --> A[Check assigned event access]
    D --> C[Application decides whether checkout is intended]
    R --> O[Distinguish owner from assigned person]
    A --> Y[Handle true or false decision]

Choose the path for your task. A listing or an owned pass does not itself grant access. For an intended purchase, use the already documented checkout/account guide; this guide does not create a pass or perform payment. For content, request its separate content-access decision. Choose owner assignment or invitations, then the separate recipient and credential tasks when needed.

Owner assignment versus invitation

Direct assignment and invitation creation are alternatives. Both require the owning member and an unassigned pass in the selected event resource. Direct assignment can attach/replace membership relationships and attempts credential-related events. Invitation creation leaves assignment for the intended recipient’s later action; the code is obtained through the existing configured invitation flow. Never substitute an invite code, pass authorization token or member session token for one another.

Recipient and credential decisions

1. The intended recipient uses their existing active member context to validate a supplied pass invite code. This is not a guest preview.
2. If acceptance is intended, activation rechecks the code/email/resource and attempts assignment/invite/account writes. It does not generate a pass authorization token.
3. Separately, an already issued pass authorization token can be exchanged for the assigned user’s member session token without a member header. The source rejects event ends earlier than 24 hours from now; token is not consumed, but repeat success is not guaranteed.
4. As the assignee, obtain the event-access decision. Article access remains separate.

flowchart TD
    I[Issuer-provided invite code] --> V[Recipient member validates]
    V --> A[Recipient member activates]
    A --> P[Attempt assignment and conditional membership]
    P --> E[Separate event-access decision]
    T[Existing pass authorization token] --> X[Resource-context credential exchange]
    X --> S[Assigned user session token]
    S --> E

There is no arrow from invitation activation to pass-token issuance: that handler does not generate one. Credential exchange can write sessions/history and attempt Firebase provisioning; it is not an event/content decision. A queue-send attempt or saved value does not confirm delivery or that all account changes succeeded together.

The owner can separately replace pass extra. This uses strict ownership but does not check event-resource association; it replaces sanitized data and does not grant access.