Three things, the first on its own.
**Auto-scroll moves the tile, not the board.** `scrollIntoView` walks up and
scrolls every ancestor that can scroll, so bringing the current item into
view dragged the whole dashboard with it whenever the board was taller than
the window. The list's own `scrollTop` is moved instead, measured from
rectangles because the rows' offset parent is the tile rather than the list.
**The current item fills as its song plays.** When an AbleSet module is
installed, configured and playing a song that IS the item on screen, that
item's background fills left to right with the song. The song is tied to a
plan item by the same name matching the live ProPresenter document already
uses, so a bar can never quietly fill the sermon while the band rehearses
something else.
**Its sections slide past, bottom right of that item.** Every section of the
song as a strip, the played ones dimmed, the one playing filling in turn and
kept centred — by moving that strip's own `scrollLeft`, for the same reason
as above. The chips are rebuilt only when the song changes; moving to the
next section just moves the classes, so the strip keeps its place.
Both are switches in the tile's gear, **Song progress** and **Song
sections**, and both draw nothing at all unless there is an AbleSet module
to follow: the server reports `available: false` for no module, a disabled
one, or one with no host, and re-checks every 15 s so installing AbleSet
later lights it up without a restart.
The server follows the AbleSet module over loopback exactly as it follows
ProPresenter's, and republishes a small slice — song, sections, playhead in
beats with a stamp — as its own `ableset` SSE event. Its own event because
it moves five times a second and must never drag the plan (items, teams)
onto the wire with it; the tile carries the playhead forward from the tempo
between packets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The module now offers two tiles in the ＋ picker, Plan and Teams, sharing
the one Planning Center connection and the one poll.
Teams draws the current plan's team and position assignments: each team as
a band of its people, with the person's photo, their position and a dot for
confirmed / unconfirmed / declined. Photos are proxied and cached by the
module (GET /team-avatar/<planPersonId>) so no browser ever talks to
Planning Center; a person with no photo gets their initials.
Everything shown is the tile's own choice, so two tiles can differ:
- Teams and Positions — a switch per team and per position, all on until
someone flips one (GET /teams, GET /positions feed the lists)
- Colours — a picker for the team headers, or Tint teams to give each its
own, optionally carried into the rows, plus the header fade and pickers
for the three statuses
- Show — twelve switches (top bar, team headers and counts, avatars,
positions, group by position, status, notes, declined and unconfirmed
people, teams nobody is on, columns)
Server: team_members?include=team,person rides a slow lane (re-read on a
plan change, else at most once a minute) and can never fail the plan read —
a lost roster keeps the last good one and says so. The service type's own
team list is read too, cached ten minutes: Planning Center only returns a
team once somebody is scheduled on it, so that list is the only way to show
a team nobody has signed up for.
No shell changes: picker entries carrying their own instanceSchema, the
colour field and multiselects all already exist.
tools/pco-mock.js grows team_members, the service type's teams and stand-in
avatar images, including a declined person, people with no photo and a team
nobody is on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Section headers lose the bracket look (no accent bar, no rounded corners)
and span the full tile width, with text still aligned to the other rows.
A "Colors" group in the gear menu holds swatch pickers for the song key,
section headers and the current item, a switch for fading the header color
to the right (on by default), and the item-type tint. Colors apply as CSS
custom properties on the tile.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- Drops the separate setup page: the service type is a select grouped by
Planning Center folder path (GET /service-types), the pinned plan a
select of upcoming/recent plans that follows the chosen service type
(GET /plans?serviceTypeId=), credentials sit in a group that folds once
saved.
- Show/hide moves from per-tile settings to a server-wide checklist in
Admin (three columns, folded by default): top bar, series, part, service
type, date, service time, total length, running clock, countdown,
headers, item numbers, start times, length, type badge, key, arrangement,
author/CCLI, description, notes, pre/post-service items, now indicator,
item runtime, dim completed, ProPresenter line. Tiles keep only text
size and auto-scroll.
- Top bar text is a template with placeholders ({series} • {part} |
{serviceType} • {date} by default; • separates droppable segments, |
starts the second line).
- Song key: larger, admin-chosen color (blue by default), always right
after the title and before the type badge. Section headers are
full-width accent bands. Optional background tint per item type.
- tools/pco-mock.js plan titles are part numbers, as in a real series.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
New module modules/pco-plan: reads the current plan for a chosen Planning
Center Services service type (PAT or OAuth token), streams items with start
times, lengths, keys, descriptions and item notes to tiles (every detail a
per-tile show/hide setting), and follows the propresenter-now-next module's
live item over loopback SSE to highlight the current plan item and track
elapsed vs planned runtime. Ships its own setup page
(/modules/pco-plan/setup.html) to browse folders and pick the service type
through the shell admin API, plus tools/pco-mock.js for development.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
