Boosters · the booster_pta role, console & PII wall, for a band program
A band program’s booster club runs fundraisers, tracks a treasury, and coordinates events, the same as any other school booster club. School Band Network does not build a second booster engine for that: the booster_pta role, its console, and its data-layer PII wall are built and run on boosterclub.software’s platform substrate; game-night ticketing, concessions, and spirit merch for the program’s own events are built and run on schoolbooster.network’s platform substrate. This page is the band-parent booster’s map to both, in one place, framed for a band program specifically.
The SEPARATE ENTITY treasury, the dues-roster obligation engine, and the exact-cent fundraiser split engine for THIS band program are on School Band Network’s own home page and schoolbooster.network — not re-described here.
Reused from boosterclub.software
Consent-as-architecture: the wall is the feature. These three facts are the core of the booster_pta role’s data-layer privacy guarantee, built and run on boosterclub.software.
The platform has one predicate that decides whether a role must never receive the student-data grant: deniesStudentData. It returns true for exactly two roles: commissioned reps (account_manager) and booster/PTA parents (booster_pta). Both are denied by the same function, so the grant site and every route guard read the same answer. There is no secondary string comparison to drift.
Built
A booster_pta session returns zero rows from every student-coupled table. This is not a WHERE clause in application code. It is a RESTRICTIVE Row Level Security policy at the database engine that fires before any application query can read a row. A route that forgets to check the role gets the same result: zero rows. The wall does not depend on the application remembering to apply it.
Built
When a donation is recorded, the donor’s name is reduced to first-name plus last-initial at write time using the platform’s firstNameLastInitial transform. Campaign progress surfaces only sums and counts: settled gift total, pending gift total, goal percent, donor count. Donor identity is not stored in the progress aggregate.
Built
Reused from boosterclub.software
A booster officer creates and tracks a fundraiser; a treasurer reads the rollup. The console runs on the cross-catalog no-split donation lane -- not the program-level split engine (see the band below for that distinction).
A booster officer creates a named campaign with an optional goal and an optional active window. The campaign rides the existing cross-catalog no-split donation lane: funds settle 100% to the school. There is no settlement leg to the platform or a studio. The campaign list shows each campaign with its settled (paid) progress.
Built
A donation decomposes the charge into gift and covered-fee legs (if the donor opts to cover processing), returns pending_payment plus a real client secret, and the paid status flips only when the payment_intent.succeeded webhook fires. No route in the platform ever fabricates a paid status.
Built
Campaign progress returns: settled gift sum (paid donations only), pending gift sum (submitted but not yet confirmed by webhook), goal percent, and donor count. These are aggregate numbers. Donor identity is not in the response.
Built
The treasurer rollup returns a summary across all of the school’s campaigns: total settled gift sum, total pending gift sum, goal percent across all campaigns with goals, and total donor count.
Built
A fundraising-event config row is created in draft status: a named event with a date, a venue, and a volunteer-slot structure. The named-slot structure lets a treasurer assign coordinator roles to an event before it runs.
Built
Reused from boosterclub.software
The server returned 200. The campaign list, progress totals, treasurer rollup, or event config is real data from the shipped engine. The console renders it directly. No fabrication.
The server returned 403. This surface is off-limits for the current session — either the role does not hold the booster gate (a plain school staffer who is not a booster_pta or admin), or the surface is the student-data wall (denyStudentData fired on the directory endpoint for a booster_pta session). The console shows the honest restricted state rather than an empty table.
The server returned 404 or 501, or the endpoint was unreachable. The booster/PTA module is not provisioned for this school, or the route is not yet live. The console shows the honest unavailable state rather than pretending the surface is empty.
The server returned 200 but the result set is empty. No campaigns, no events, no treasury entries yet. The console shows an honest empty state rather than a placeholder or demo row.
Reused from boosterclub.software
The treasurer rollup splits the gift total into two buckets: settled (donations confirmed by the payment_intent.succeeded webhook — real, cleared funds) and pending (donations submitted but not yet confirmed by the webhook). The console shows both, labeled honestly, rather than combining them into a single inflated total.
Built
If a campaign was created with a goal, the progress response and the treasurer rollup include the goal percent: how far the settled total has progressed toward the goal. Goal percent is computed from settled funds only — pending donations do not inflate the progress bar.
Built
The progress response and the treasurer rollup include a donor count: the number of distinct donors who have made a settled donation to the campaign. Count only — no names, no amounts per person.
Built
Reused from schoolbooster.network
A band booster does not only run a treasury -- it runs a marching band competition gate, a concert-night concessions stand, and a spirit-merch table. These three pillars are built and run on schoolbooster.network’s platform substrate.
The box-office engine manages ticket types, pricing, and per-event capacity for every game and performance on a program’s schedule. Season passes and multi-game packages let an athletics booster sell a full-season commitment in one transaction. Reserved-seating shapes support a theatre house with assigned rows; general-admission capacity limits support a stadium gate. A no-oversell rule is enforced at the data layer — a ticket type with a set capacity cannot sell one beyond that limit, not by disabling a button but by refusing the transaction at the engine. Gate-scan handles door check-in at the entrance, marking each ticket admitted against the ticket record in real time. The box-office engine and gate-scan foundation are built and production-ready. The live checkout interface that accepts payment from ticket buyers is honest-off — present in the platform, not enabled for live transactions today.
Box-office engine built · live checkout honest-off
The concessions point-of-sale rings up items with per-item pricing in a cart and totals each sale to the exact cent. Cash is the base tender, and the till is fail-closed — a cash sale cannot complete under-tendered. At close, the till reconciles: it opens with a counted float, and the drawer is counted against expected cash so any variance is surfaced. Each sale records its exact-cent total and the number of lines rung up. Card payment runs through the payment rail, which is honest-off today. The concessions POS engine — cart, per-item pricing, cash tender, and fail-closed till reconciliation — is built and production-ready. Card payment at the stand is honest-off — present in the platform, not enabled for live card transactions. Per-event inventory tracking and volunteer stand-shift assignment are on the roadmap, not built today.
Concessions POS built · card payment honest-off
The cart substrate and catalog management are built on the platform’s commerce layer. Spirit wear, program merch, player packs, and senior banners can be catalogued against a program, associated with a season, and added to a cart. The storefront — the customer-facing interface where a parent browses the catalog and checks out — is honest-off: the checkout interface that accepts payment does not yet go live. Spirit merch is described accurately: cart primitives and catalog on a built substrate, with the storefront checkout honest-off while in active development. No live team store claim is made here.
Cart substrate built · storefront checkout honest-off
What this page does not rebuild
School Band Network already owns the band program’s own booster treasury: the SEPARATE ENTITY flag that keeps the club’s books distinct from the school’s administrative accounts, the dues-roster obligation engine (paid / owed / waived, summed to the cent, with a fail-closed hardship-waiver gate), and the exact-cent fundraiser split engine (fee-off-gross-first, largest-remainder reconciliation). That content lives on School Band Network’s own home page (the booster-treasury pillar) and, for the split engine and the season/program-run box office, at schoolbooster.network. This page does not re-describe either -- it cross-links both rather than carrying a second, potentially drifting copy of the same governance and money logic.
What this page adds is the piece those two do not cover: the booster_pta role itself, the console a booster officer and treasurer actually use, and the data-layer PII wall behind it -- reused from boosterclub.software, cited above.
Band students are minors — program data only
The booster_pta role is denied student data at the data layer: deniesStudentData(booster_pta) === true, enforced by a RESTRICTIVE Row Level Security policy before any application code runs. A booster officer’s console shows program data only -- campaigns, events, and treasury sums -- never a roster of student names. A family reaches its own student’s information through the platform’s consent substrate, not a public page any visitor could browse. No family sees another family’s student.
What is built and what is honest-off — plainly
Built and production-ready today, reused from boosterclub.software: the booster_pta first-class role; the PII wall (deniesStudentData(booster_pta) === true, zero student rows at the data layer); fundraiser creation and tracking on the no-split donation lane, with honest pending_payment state; the treasurer aggregate rollup; event coordination; and the four honest console states. Built and production-ready today, reused from schoolbooster.network: the box-office engine and gate-scan foundation, the concessions point-of-sale engine, and the cart substrate and catalog for spirit merch.
Honest-off, exactly as both cited sources state, never upgraded here: the live checkout interface for ticket buyers, card payment at the concessions stand, and the storefront checkout for spirit merch. There is no live checkout, no billing, and no subscription on this page.
Connected to the band-program platform
For the booster_pta role, the console, and the PII wall in full depth, boosterclub.software is the dedicated apex. For box office, concessions, spirit merch, and the exact-cent split engine, schoolbooster.network is the season/program-run operating platform. For the dues-roster engine on its own, dues.software is the sibling home. And the whole band program — ensembles, the season calendar, instrument records, and this booster page — lives at School Band Network’s own home page.
Get started
There is no pricing commitment and no signup on this page. A conversation shows the current, honest state of the booster_pta console on boosterclub.software and the game-night operations on schoolbooster.network.
To book: email [email protected].
FAQ
The booster club's treasury is kept distinct from the school's own administrative accounts at the data layer — a SEPARATE ENTITY, not a line item folded into the school's books. The booster role is FERPA-walled: a treasurer's own view is sums-only aggregates, counts and cent totals per season, never an individual student's row or a name list. A financial-hardship waiver reason on the dues roster is held for the treasurer's own audit only and never appears in any export or family-facing view. This is enforced at the data layer, not a policy memo or a UI filter a route could forget.
Not yet. The dues-roster obligation engine, the SEPARATE ENTITY treasury, and the exact-cent fundraiser split engine are built and production-ready — the balance math, the hardship-waiver gate, and the distribution logic are all there. The charge rail that actually moves money — dues checkout, fundraiser checkout, any live payment — is honest-off: present in the platform, not enabled for live transactions today. There is no live checkout, no billing, and no subscription on this site. The CTA here is “book a conversation,” not “collect dues now.”
No. Band students are minors, and the band roster is never a public page. A booster treasurer's view is sums-only aggregates — never a student's name or row. A family reaches its own student's record only through the platform's consent substrate: the single-school wall and the do-not-publish kill-switch that back the whole platform, not a public roster anyone can browse. No other family sees another family's student. Student and family data is never sold or shared with outside companies or advertisers.
It is a real, separate role: a first-class value in the platform’s user-role enum, with its own DB entry, its own API route group, its own require-booster gate, and its own web console surface. It is never folded into the school coordinator role. A school coordinator and a booster/PTA parent are separate actors with separate access profiles. The booster_pta role is always denied student data at the data layer.
No. The directory endpoint calls denyStudentData, which returns 403 for a booster_pta session. The console renders the honest restricted state for the directory when the session is booster_pta. A school official (adviser or admin) may access the consent-cleared directory; a booster parent may not. This is enforced server-side on every request, not just in the UI.
The treasurer sees settled gift total, pending gift total, goal percent, and donor count across all campaigns. No individual donor names, no per-donor amounts. Donor identity is reduced to first-name plus last-initial at write time; the progress aggregate does not surface even that — it surfaces only the count.