Skylar Grant
b29c0a022d
The per-user sign-in was tested live on bare metal behind NPM: Zoho sign-in, SDP data, Sign out and the IP access list all work. Token renewal and the first Docker deploy are still to check. - README: section on testing on the server without Docker (Gitea holds port 3000, NPM runs in Docker so forward to its network gateway, keep PORT out of the production .env), plus Cloudflare proxy and access list notes. The screenshots are removed until they're retaken. - NOTES: deployment gotchas from the test run. - ROADMAP and SESSION: what's verified, what's left, new resume prompt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
43 lines
4.3 KiB
Markdown
43 lines
4.3 KiB
Markdown
# Roadmap
|
||
|
||
## Goal
|
||
|
||
A hosted dashboard for MCCS help desk staff. Everyone signs in with their own Zoho account and sees the queue for their region. Each browser can be customised, and new panels are easy to add.
|
||
|
||
## Current architecture
|
||
|
||
- **Hosting:** Docker image on a VPS behind Nginx Proxy Manager, which only lets in MCCS' public IP blocks. The image is built by Gitea Actions; the container is restarted by hand.
|
||
- **Identity and data:** each user signs in with their own Zoho account (web OAuth, Server-based Application client), and every SDP query runs with that user's token. What a user sees is limited by their own SDP permissions and then by the region filter.
|
||
- **Sessions:** the Zoho tokens live in an encrypted, `HttpOnly` cookie. The server stores nothing, so restarts and upgrades don't sign anyone out.
|
||
- **Polling:** the browser runs the checks (closed feed every minute, status table every `WORKLOAD_MINUTES`) and keeps the closed feed. The server answers each call with the caller's token and caches nothing per user. Only the weather is shared.
|
||
- **Region:** central region only, from `.env` (`SITE_NAMES`, `GROUP_NAMES`, `TECHNICIAN_NAMES` and the status lists).
|
||
|
||
## Next
|
||
|
||
- [ ] **Finish checking the rebuild live.** Done on 2026-10-15 with a bare-metal test run behind `dash-test`: Zoho sign-in, live SDP data, Sign out, and the NPM access list (403 from mobile data). Still to check: the token renews after an hour without a sign-in prompt, and the first `v*-prod*` image builds, starts healthy and serves the production subdomain.
|
||
- [ ] **Per-browser settings** (planned, not built). A settings panel, or a setup prompt on first launch, that saves choices in the browser (`localStorage`): sites, groups, technicians, which statuses count as closed, unassigned exclusions, sound, hidden columns. Design notes:
|
||
- `/api/session` already returns the `.env` region as `settings`. The panel starts from those defaults, and "reset" goes back to them.
|
||
- The page would send its settings with each `/api/closed` and `/api/workload` call (query string or a JSON header). `routes.js` currently passes the server's `settings` object to `tickets.js`. That becomes "defaults merged with the validated request", and `tickets.js` needs no change because it already takes these as arguments.
|
||
- The server must validate what the browser sends (lists of plain names, length caps, minimum refresh intervals). That's to protect SDP and the server, not for access control: data comes from the user's own token, so changing the region can never show more than SDP already lets that user see.
|
||
- Pick lists for sites, groups and technicians could come from SDP, but that probably needs another scope (check which, e.g. a setup or users read scope). Adding a scope means everyone signs in again.
|
||
- Export and import settings as JSON, so a region's setup can be shared without a server-side store.
|
||
- Weather location (`OWM_ZIP_CODE`) could become a setting too. The server cache would then need to be keyed by zip.
|
||
- [ ] **Panel modules:** each panel has a server route to fetch its data and page code to draw it. The weather card is the model.
|
||
- [ ] **Status table width:** it scrolls sideways once there are more statuses than fit (see `NOTES.md`).
|
||
|
||
## Open questions
|
||
|
||
- Does SDP restrict technicians to certain sites? With per-user tokens, that decides whether someone in another region sees their region's tickets or nothing.
|
||
- How many dashboards will be open at once? Each one polls SDP with its own token, so check the SDP API rate limits if wallboards multiply.
|
||
|
||
## Done
|
||
|
||
- Dashboard: stat tiles, technician × status table, live closed feed with the ding.
|
||
- Central region scoping by site and group.
|
||
- Unassigned counter. Verified to match the ManageEngine "Central Region Unassigned" view on 2026-10-15.
|
||
- Weather card (OpenWeatherMap).
|
||
- Fixed SDP paging and the date filter (see `NOTES.md`).
|
||
- Server-based auth rebuild (2026-10-15): per-user Zoho web sign-in, sessions in an encrypted browser cookie, a stateless server, and the browser running the checks. This replaced the shared device-code token, the `ADMIN_KEY` and `data/token.json` from the short-lived phase 1.
|
||
- Docker image `v0idf1sh/sdp-dashboard`, an example `docker-compose.yml`, and a Gitea Actions build on `v*-prod*` tags.
|
||
- Live test on 2026-10-15: per-user sign-in, data, Sign out and the IP access list all work behind NPM.
|