Zayin/Ekklesia
3
0
Fork 0
Code Issues 6 Pull Requests 2 Actions 1 Packages Projects Releases 9 Wiki Activity

Pair displays at the platform's own /display/setup, with or without modules
CI / verify (pull_request) Successful in 1m12s
Details
CI / infrastructure-smoke (pull_request) Successful in 45s
Details
CI / package-release (pull_request) Successful in 50s
Details
CI / migration-smoke (pull_request) Successful in 2m34s
Details
CI / image-build (pull_request) Successful in 1m8s
Details
CI / deploy-smoke (same-origin) (pull_request) Successful in 51s
Details
CI / package-publication (pull_request) Successful in 57s
Details
CI / deploy-smoke (split) (pull_request) Successful in 3m52s
Details

Browse Source 
Displays are platform-owned, but a screen could only start pairing on a
module's display page: every pairing request named a module, so an
installation with no module that uses displays could not set one up.

- /display/setup is the platform's own display page, served whenever
  the deployment has device support, whatever is installed. It pairs a
  platform display with no module. Once paired, it opens the module it
  is set to show; with none set, it shows its name and waits, rechecking
  so it stays alive and notices revocation. "setup" is now a reserved
  module id.
- Migration core:0009_platform_display_pairing lets a pairing request
  name no module. It relaxes module_id and permission_id and adds a
  both-or-neither check. It is additive and destroys nothing.
- POST /api/v1/device-pairing/requests accepts {} for a platform
  display. Approval accepts an optional moduleId, so the administrator
  can choose an installed display module and the device gets that
  module's declared permission. A module display's own request can't be
  redirected.
- GET /api/v1/device-pairing/self lets a paired device describe itself:
  its name and the module displays it may show. It renews the device's
  cookie.
- GET /api/v1/devices/setup is replaced by
  GET /api/v1/devices/display-modules: the modules a display can be set
  to show.
- Settings -> Displays always offers the /display/setup address, Copy
  setup link and Add display. Add display has an optional "Show on this
  screen" choice, and each paired display says what it shows.
- /display/<module-id> is unchanged, so released Signage 0.1.5 works as
  before.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
ekklesia
2026-10-16 16:43:02 -05:00
co-authored by Claude Opus 5.5
parent 906c015ca8
commit 300d9eab51
44 changed files with 3169 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+3 -2
View File
@@ -955,8 +955,9 @@ links to where each is changed; the platform's General, Branding, Displays, Disc
each module's settings at `/settings/<module-id>`. Discover is where modules are found and installed
(`/settings/discover`), with Installed and Updates beneath it (`/settings/discover/installed`,
`/updates`); configuring a module is its own Settings page. **Settings → Displays** sets up, pairs, and revokes
display screens: how to start a new screen (the platform display page to open on it, with Copy link),
the paired displays with when each was last seen, and an *Add display* flow for the code a screen shows
display screens, whatever modules are installed: a new screen opens the platform's own
`/display/setup` and shows a code; *Add display* names it and, optionally, chooses which installed
module it shows; the paired displays show what each shows and when it was last seen
([ADR 0064](docs/architecture/decisions/0064-stage-1-shell-review-corrections.md),
[ADR 0065](docs/architecture/decisions/0065-display-setup-phone-forms-and-drawer-scroll-lock.md)).
A person sees only what the server says they may administer, and no Settings link at all when that is