Pass Roster
The Pass Roster as a connector's creator surface reads it one date at a time — the plans that sell dates, a plan's coming dates with their roll call, the holders of one date with where each stands, and one pass's trail of moves.
Subscriby\Connector\Core\PassRoster. The dashboard draws the Pass Roster as a grid of members against dates; a chat has no grid, so this port walks it the way a conversation can. Every call takes the CreatorRef of the account talking and runs as that creator under the members list's own permission, and every refusal reaches you as PassRosterRefused with a stable reason. The words are the core's: a standing and a move reason cross as enums with the dashboard's translated word beside them, and a date with its range in the plan's own time zone, so your surface prints what the page prints. The Telegram platform bot's 📋 Pass Roster screens and Discord's /subscriby-admin roster are the first callers.
plansFor()
foreach ($this->roster->plansFor($creator, $project) as $plan) {
// $plan->name, $plan->kind, $plan->datesAhead
}The plans that sell dates, passes and seasons alike, by name, each a PassRosterPlan: the id, the project, the name, the kind (PlanKind::Pass or PlanKind::PassSeries) and how many of its dates are still to come, cancelled ones left out.
datesFor()
$list = $this->roster->datesFor($creator, $plan->id, weeksAhead: 8);
foreach ($list->dates as $date) {
// $date->localRange, $date->dayLabel, $date->isCancelled(), $date->sold, $date->queued
}A PassRosterDates: the plan, and its dates that have not ended and start within the weeks, soonest first, cancelled ones included and marked. Each is a PassRosterDate with its range and its day label in the plan's zone, its state as an AccessWindowState (scheduled, open, closed, cancelled) and its roll call: sold counts every purchase ever bound to the date, refunded and cancelled ones included, and active, queued, notQueued and refunded explain the gap between it and how many will walk in. A plan that sells no dates is refused as plan_unknown.
holdersOf()
$page = $this->roster->holdersOf($creator, $date->id, page: 1, perPage: 8);
foreach ($page->holders as $holder) {
// $holder->memberName, $holder->standing, $holder->standingWord, $holder->movedFrom, $holder->passId
}A PassHolderPage: the date with its roll call and one page of its holders in the order they bought. A holder is a pass, so the same member holding a date through two purchases is two holders; each PassHolder carries the pass id, the purchase, the member and their name, their standing beside the dashboard's translated word for it, the plan, whether the date is held through a season, the date the pass last came from and its id, when they bought and when they were last reminded. lastPage(), hasPrevious() and hasNext() page it; a page carries at most a hundred.
| Standing | Meaning |
|---|---|
in | Admitted to the date. |
queued | In the join queue, admitted when the date opens. |
holds | Holds the date and has not joined the queue yet: the one to nudge. |
missed | Held the date and never joined; the date ran without them. |
ended | The date ended, or access to it was taken away. |
covered | Holds the date through another purchase as well, and that purchase is the one that admits them. |
trailOf()
$trail = $this->roster->trailOf($creator, $holder->passId);
foreach ($trail->hops as $hop) {
// $hop->fromLabel, $hop->toLabel, $hop->reasonWord, $hop->movedByName, $hop->movedAt
}A PassHolderTrail: the holder, the date their pass is on now with its roll call, and every hop the pass made from the core's move log, oldest first. Each PassHop names both dates by id and by day label (toDateId and toLabel are null when the pass was ended instead), the reason as a PassMoveReason (window_cancelled, series_date_substituted, paid_after_window) beside its translated label, who made it when a person did, and when. A pass that never moved has no hops.
One date at a time
The port reads a plan, a date or a pass by the id a button carried, resolves the project behind it as the creator and checks the members list's permission before wording anything, so a stale or borrowed button answers a refusal and never a stranger's roster.
Refusals
| Reason | When |
|---|---|
creator_unknown | The ref names no creator. |
project_unknown | The project is not one the creator may manage. |
plan_unknown | The plan is not one the creator may manage, or it sells no dates. |
date_unknown | The date is not one the creator may manage. |
pass_unknown | The pass is not one the creator may manage. |
not_permitted | The creator may not read the project's members. |
How is this guide?
Last updated on
Creator Tasks
A project's creator tasks as a connector's creator surface lists and settles them — what a member bought that the creator hands over by hand, listed by state and marked done through the dashboard's own action.
Alerts
Where a creator's alerts go, as far as a connector may ask or change it — the one switch for the account in front of the connector, and what the core keeps to itself.