Passa al contenuto principale

Web UI

Usa questa pagina per consultare percorsi, autenticazione, schermate e comportamento responsive.

afe serve --ui serve una web UI sullo stesso host e sulla stessa porta dell'API. È un bundle statico che vive nel pacchetto Python afe-web: al momento di servirlo non gira Node.js e non si distribuisce nient'altro.

export AFE_API_TOKEN=$(openssl rand -hex 32)
afe serve -c config/ --ui          # apri http://127.0.0.1:8765/
afe worker -c config/              # in un altro terminale: la UI mostra i ticket che esegue

Accesso​

La UI chiede una volta il token API del motore. POST /auth/login imposta un cookie di sessione HttpOnly e SameSite=Strict (firmato con una chiave derivata dal token, e Secure dietro HTTPS), così il JavaScript non tiene mai il token. Una sessione dura 8 ore di default (--session-hours). GET /auth/session dice alla pagina se è autenticata; una connessione persa che torna 401 riporta l'utente al login. Il WebSocket /rpc accetta quel cookie solo quando l'Origin della richiesta è quello del server; la CLI continua a usare il token Bearer.

Schermate​

RottaPaginaCosa fa
/Dashboardi ticket per stato, filtri per stato e flow, una ricerca su id del ticket, uid e progetto, la lista viva con il costo, ordinabile su ogni colonna; una riga apre il ticket
/tickets/:idTicketintestazione e totali con i token in cache e quelli freschi, la richiesta in sospeso, il BPMN del flow con il nodo corrente, la timeline viva, gli artefatti; pausa, annulla, riprendi e riesegui
/approvalsApprovazioniogni ticket in attesa di una persona, risposto sul posto
/flows, /flows/:nameFlowi flow della revisione corrente, ognuno con il suo BPMN e un pulsante di avvio
/flows/:name/startAvvia un ticketun form generato dallo Schema d'ingresso del flow; ?rerun=<id> lo compila da un ticket
/revisions/:idRevisioneuna revisione e i suoi manifest, YAML in sola lettura
/workersWorkeri worker vivi e la coda, aggiornati ogni 2, 5 o 10 s, oppure in pausa

Un nodo human può indicare le azioni la cui risposta richiede un commento:

approve:
  type: human
  actions: [approve, reject]
  requireComment: [reject]

Nelle pagine Ticket e Approvazioni un'azione così apre una conferma con il commento obbligatorio; il motore rifiuta la risposta senza commento, dalla UI, dalla CLI o dall'API (INVALID_INPUT).

Ogni schermata si aggiorna dal vivo da una sola events.subscribe su /rpc, mostra uno stato di caricamento, vuoto ed errore, e si riconnette con un banner quando il WebSocket cade. La UI parla inglese e italiano da un file di messaggi per lingua; la scelta è ricordata nel browser e date, numeri e costi seguono la lingua. Il BPMN è disposto automaticamente (bpmn-auto-layout) e mostrato in sola lettura con zoom e pan (bpmn-js); la filigrana bpmn.io resta, come chiede la sua licenza. In un ticket, un pallino rosso segna il nodo corrente; un clic su un nodo, un gateway o un evento di pausa ne mostra id, tipo e ultimi eventi, e lo borda di blu. Gli eventi di pausa (i cerchi tratteggiati sui task degli agenti: l'agente può fermarsi per il budget o per l'anti-loop e aspettare una persona) stanno nell'angolo in alto a destra del loro task. Il diagramma si apre centrato in un riquadro alto quanto il diagramma, tra 160 px e il 60 % dell'altezza della finestra; "Adatta" lo adatta e lo centra di nuovo.

Su telefono e tablet​

La UI funziona da 360 px in su e non scorre mai di lato: id lunghi, JSON e YAML vanno a capo o scorrono dentro il proprio riquadro. Segue i breakpoint di Material UI:

LarghezzaLayout
sotto i 600 px (telefono)il layout descritto sotto
600–899 px (tablet)le pagine desktop, impilate in una colonna; le tabelle tengono tutte le colonne
da 900 px (desktop)affiancate, come descritto sopra

Sul telefono:

  • Barra in alto: il menu, afe e la campanella delle attese. Lingua ed "Esci" stanno in fondo al menu di navigazione.
  • Tocco: ogni pulsante, riga cliccabile e card è alto almeno 40 px, e niente richiede l'hover.
  • Dashboard: i conteggi per stato sono una riga di chip, ogni stato con il suo numero. La ricerca viene prima, i filtri per stato e flow stanno insieme sulla riga sotto. Ogni ticket è una card (id, stato, flow, round, costo e progetto se c'è) che apre il ticket. Un menu "Ordina per" e un pulsante freccia sostituiscono le intestazioni delle colonne.
  • Ticket: l'id, sotto lo stato, poi le azioni. Dettagli e totali sono uno per riga. Commento e pulsanti del pannello della richiesta occupano tutta la larghezza. Seguono, in quest'ordine, il diagramma, il pannello del nodo, gli eventi e gli artefatti.
  • BPMN: il diagramma si apre al 100 %, centrato sul nodo corrente del ticket (o su START) quando è più largo dello schermo. Si sposta trascinando con un dito e si ingrandisce con due dita; sopra il diagramma la pagina non scorre. Toccare un nodo apre il suo pannello e ci scorre sopra.
  • Approvazioni, Flow, Avvio, Worker: card, campi e pulsanti occupano tutta la larghezza. I worker sono card (worker, host, pid, ticket sulla concorrenza, ultimo contatto). Il chip della revisione del flow mostra i primi 12 caratteri dell'id.

Cosa non fa​

  • Non modifica flow o manifest, e non disegna flow.
  • Ha un solo token, senza utenti o ruoli.
  • Non ha un tema scuro.
  • Non è un'app installabile (PWA): niente uso offline né notifiche push.

Vedi anche​