Web Console

The staff side of the Job Adding System

Job 360 for any job across every system, a Data health page for the mirror, on-demand reports, live actions behind a confirm, a job editor with an audit trail, revenue and stock forecasts, and a System module rendered from the automation catalog.

Staff across operations, finance and sales sign in to look a job up, run an automation when they need it rather than wait for its timer, and fix what a job carries without asking a developer. It is a thin layer over the Job Adding System: the business logic stays in the automations, and the console calls the same code they run.

What staff use it for

Look it up, run it, correct it

Job 360

One record for a job, built from what every platform holds about it. Each field shows which system it came from, rows where two systems disagree are flagged so they can be fixed before they cost anything, and a day-by-day timeline lists every field change the mirror has seen.

Data health

The mirror copies the work boards, the CRM and the rebate platform into a local database every fifteen minutes, reading only. Data health shows each source's freshness against that interval, its record counts, a strip of its last eight runs and the first line of any error, over a filterable run history.

Reports on demand

The Tools view runs the reports that otherwise arrive on a timer: weekly sales, installer forms, the stock order, timesheets, the weekly rebate summary and installer capacity calendars. Each builds on the server and comes back as a real spreadsheet, and several can be picked and run in one go.

Live actions behind a confirm

Raising a draft invoice or creating a rebate job runs the real automation for one job and only that job: a preview first, then an explicit confirm. Rarer repairs, such as un-sticking a job held for review, ask for the job number typed back before they run. Running one again is safe, because an invoice that exists is never rebuilt.

A job editor with an audit trail

When a customer drops three panels or the agreed price moves, operations correct the job here. The server shows exactly what saving will do, and a reason is required before it saves. The change is kept as a new registry record on top of the signed one, which is never altered, and reaches the job card, picking slip, invoice, stock order and certificate from that single point; an invoice already raised is flagged in the preview instead.

Stock and revenue forecasts

Stock shows what the scheduled installs need, per product, per week and per job, from the same breakdown as the weekly stock order, and names any job not in the numbers. Revenue shows the open pipeline in money: contract, deposit received, balance owed and certificates valued at a price the reader sets. Both export to Excel.

The System module

A service catalogue rendered from the automation catalogue, which is updated in the same change as the code. Every automation is a row with its status, how often it runs, the platforms it touches and the departments it serves; its page shows what it reads, what it writes, its flowchart and related systems.

Ask JAS

A question box over a fixed set of read-only checks: why a job is stuck, what ran overnight, what is overdue. A language model hosted in Australia picks the check, or asks when unsure, and the one-line answer is written by code from the check's verdict, so it cannot contradict the evidence. The same checks serve JARVIS.

Sign-in and audit

Proving who you are does not get you in

Who gets in

  • Single sign-on with Microsoft Entra ID, enforced at the edge before a request reaches the server; the app then makes its own checks.
  • Signing in proves identity only. Every API route checks the person against an allowlist kept in code, so a change to who has access is a reviewed commit.
  • Pages that show money, such as Revenue, have a narrower list of readers of their own; being an admin is not enough.
  • The console listens only on its own server and is reached through a tunnel. The browser never holds a credential for any platform.
  • Sessions are short-lived, secure cookies, and every request that changes something carries a CSRF token.

What gets recorded

  • Every run records who started it, what it was, its inputs, whether it was a preview, when, and how it ended.
  • The audit is read-only in the interface.
  • Each job-editor save adds an entry to that job's history, with the person's reason.
  • Editor saves carry a request id, so a double-tap cannot write twice.
  • There is no "delete all", "purge" or "reset" anywhere. Writes are scoped to one job or one date window.

How it is built

Small enough to audit

No build step

Semantic HTML, a design-token stylesheet and native JavaScript modules, served straight from the Python package. No framework, bundler or router to patch. The richer pages use one small vendored runtime, pinned as a single file and never edited in place.

A strict content security policy

No inline script or style and no third-party origin, fonts included, so the policy allows only the console's own files. The page talks only to the console's API, never directly to a platform.

Answers from a local copy

Job 360, Data health and Ask JAS read the mirror rather than calling each platform live, so they are fast, can join across systems, and still answer when a platform is down. Long runs work in the background while the page follows their status.

Accessible in both themes

Built to WCAG AA in light and dark: keyboard search, visible focus, live regions for results, and colour never the only signal. In the catalogue, status is shown by the shape of a dot as well as its colour. Every view has its own link, so a refresh or a pasted link lands on the same page.

FastAPI • vanilla JS • Preact and htm, vendored • SQLite • Entra ID • Cloudflare Access