PCO Plan 1.10.0: follow several service types in priority order, and read any of them from any dashboard #42

2026-10-06T14:33:02-04:00

michael commented

2026-10-06 14:33:02 -04:00

An account runs more than one service type — a Sunday morning, a Wednesday night, a youth service, a second campus — and until now that meant one ProdDash per type. The module now follows as many as are configured.

Picking them, in order

Shell 1.12.0 gives multiselect an orderable: true that stops being a ticklist: the picks sit in a numbered list with a nudge either way and a remove, over a dropdown holding whatever is left. Forty switches to read past is not a picker, and a ticklist cannot carry an order anyway. addLabel names the dropdown.

The order is the setting. When two types have a plan at the same date and time, the one higher up wins.

Following them

The server gathers candidate plans from every ticked type and tiers them: today's plan first, then the next upcoming, then the most recent past, with the configured order breaking a tie. A type that fails is skipped rather than failing the read — unless it answers 401 or 429, which belongs to the whole connection. The types not being followed are read on a slower lane (45 s) into state.others, so they are there to look at without a second connection.

Reading another one

Every tile's title bar carries a service-type control. Picking one moves every PCO Plan tile on that browser's dashboard — plan, teams and song key together — onto its plan, over a small page bus in viewed-type.js. The choice is per browser, survives a reload, and the control hides itself when only one type is configured.

Live machinery stays with the type being followed. Another type's plan shows its running order with no now marker, no AbleSet and no service clock — it shows that plan's own scheduled time instead. Borrowing the running clock of a different service is exactly the misreading the amber top-bar stripe exists to prevent, and this PR fixes that: the clock was reading state.service regardless of which type was on screen.

Migration

Old configs carry serviceTypeId. It is read once into the new array and saved, and plan pins still resolve bare, so nothing has to be re-entered on AB or NA.

Verified

Against tools/pco-mock.js (which now takes --types N to pad the list out, for trying the picker against an account with dozens):

42 service types — picker stays two rows and a dropdown, grouped by Planning Center folder
Priority — reversing the order flips which plan is followed, confirmed in both directions through Apply
Migration — a pre-1.10.0 config with only serviceTypeId loads and follows the same type; a bare plan pin still resolves
Per-dashboard switch — all three tile kinds move together, choice persists in localStorage, survives reload, reverts on "Whatever is live"; a newly added tile inherits the dashboard's current view
Dependent list — adding or removing a type refreshes the Plan dropdown's groups
Resilience — upstream loss turns all three tiles red with the reason and keeps the last plan; recovery without a restart; admin re-init with tiles open; tile removal leaves no listener behind (3 tiles → 3 bus listeners); two Plan tiles coexist; console and server log clean on a fresh load

🤖 Generated with Claude Code

An account runs more than one service type — a Sunday morning, a Wednesday night, a youth service, a second campus — and until now that meant one ProdDash per type. The module now follows as many as are configured. ### Picking them, in order Shell **1.12.0** gives `multiselect` an `orderable: true` that stops being a ticklist: the picks sit in a numbered list with a nudge either way and a remove, over a dropdown holding whatever is left. Forty switches to read past is not a picker, and a ticklist cannot carry an order anyway. `addLabel` names the dropdown. The order **is** the setting. When two types have a plan at the same date and time, the one higher up wins. ### Following them The server gathers candidate plans from every ticked type and tiers them: today's plan first, then the next upcoming, then the most recent past, with the configured order breaking a tie. A type that fails is skipped rather than failing the read — unless it answers 401 or 429, which belongs to the whole connection. The types not being followed are read on a slower lane (45 s) into `state.others`, so they are there to look at without a second connection. ### Reading another one Every tile's title bar carries a service-type control. Picking one moves **every PCO Plan tile on that browser's dashboard** — plan, teams and song key together — onto its plan, over a small page bus in `viewed-type.js`. The choice is per browser, survives a reload, and the control hides itself when only one type is configured. Live machinery stays with the type being followed. Another type's plan shows its running order with no now marker, no AbleSet and no service clock — it shows that plan's own scheduled time instead. Borrowing the running clock of a different service is exactly the misreading the amber top-bar stripe exists to prevent, and this PR fixes that: the clock was reading `state.service` regardless of which type was on screen. ### Migration Old configs carry `serviceTypeId`. It is read once into the new array and saved, and plan pins still resolve bare, so nothing has to be re-entered on AB or NA. ### Verified Against `tools/pco-mock.js` (which now takes `--types N` to pad the list out, for trying the picker against an account with dozens): - **42 service types** — picker stays two rows and a dropdown, grouped by Planning Center folder - **Priority** — reversing the order flips which plan is followed, confirmed in both directions through Apply - **Migration** — a pre-1.10.0 config with only `serviceTypeId` loads and follows the same type; a bare plan pin still resolves - **Per-dashboard switch** — all three tile kinds move together, choice persists in localStorage, survives reload, reverts on "Whatever is live"; a newly added tile inherits the dashboard's current view - **Dependent list** — adding or removing a type refreshes the Plan dropdown's groups - **Resilience** — upstream loss turns all three tiles red with the reason and keeps the last plan; recovery without a restart; admin re-init with tiles open; tile removal leaves no listener behind (3 tiles → 3 bus listeners); two Plan tiles coexist; console and server log clean on a fresh load 🤖 Generated with [Claude Code](https://claude.com/claude-code)

michael added 1 commit 2026-10-06 14:33:04 -04:00

PCO Plan 1.10.0: follow several service types in priority order, and read any of them from any dashboard 7bb1131378

An account runs more than one service type — a Sunday morning, a Wednesday
night, a youth service, a second campus — and until now that meant one
ProdDash per type. The module now follows as many as are configured.

Admin picks them in priority order. Shell 1.12.0 gives `multiselect` an
`orderable: true` that stops being a ticklist: the picks sit in a numbered
list with a nudge either way and a remove, over a dropdown holding what is
left. Forty switches to read past is not a picker, and a ticklist cannot
carry an order anyway. The order is the setting — when two types have a plan
at the same date and time, the one higher up wins.

The server gathers candidate plans from every ticked type and tiers them:
today's plan first, then the next upcoming, then the most recent past, with
the configured order breaking a tie. A type that fails is skipped rather
than failing the read, unless it is an auth or rate-limit answer, which
belongs to the whole connection. The types not being followed are read on a
slower lane (45 s) into `state.others`, so they are there to look at without
a second connection.

Every tile's title bar carries a service-type control. Picking one moves
every PCO Plan tile on that browser's dashboard — plan, teams and song key
together — onto its plan, over a small page bus in `viewed-type.js`; the
choice is per browser and survives a reload. The control hides itself when
only one type is configured.

Live machinery stays with the type being followed: another type's plan shows
its running order with no now marker, no AbleSet and no service clock — it
shows that plan's own scheduled time instead, since borrowing the running
clock of a different service is exactly the misreading the amber top-bar
stripe exists to prevent.

Old configs carry `serviceTypeId`; it is read once into the new array and
saved, and plan pins still resolve bare, so nothing has to be re-entered.

`tools/pco-mock.js` takes `--types N` to pad the list out, for trying the
picker against an account with dozens of them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

michael merged commit c9e03398a6 into main

2026-10-06 15:01:15 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: michael/ProdDash#42