Adriano
b913a2bf90
Refs gitea:Adriano/AI-OS#310 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
59 lines
3.4 KiB
Markdown
59 lines
3.4 KiB
Markdown
# Task 10 — Report: badge GUID + modal modifica inline
|
|
|
|
## Cosa è stato fatto
|
|
|
|
Sostituito integralmente il blocco `{showTags && (...)}` in `src/layouts/Base.astro` (righe ~76-101) con il
|
|
codice verbatim del brief: badge overlay (nome tag + guid abbreviato + pulsante matita ✎) e modal `#tag-modal`
|
|
con textarea/select per contenuti testuali, upload/rimozione file per contenuti immagine.
|
|
|
|
## Build e test automatici
|
|
|
|
- `npm run build` → OK, nessun errore.
|
|
- `npm test` → 13 file di test, 64 test, tutti verdi.
|
|
|
|
## Verifica funzionale (runtime reale, non solo build statica)
|
|
|
|
Ho creato un utente admin locale (`super`/`prova1234`, ruolo `admin` — lo script `create-user` accetta solo
|
|
`admin`/`editor`, non `superuser`; `canTags` in Base.astro accetta sia `superuser` sia `admin`, quindi admin è
|
|
sufficiente per attivare i tag).
|
|
|
|
Avviato il build di produzione (`node dist/server/entry.mjs`, porta 4399) e verificato via `curl`:
|
|
|
|
1. **Pagina anonima** (nessun cookie): `grep -c 'tag-modal'` sul body → **0**. Overlay assente per utenti non
|
|
autorizzati, come atteso.
|
|
2. **Login** via POST form a `/login` con header `Origin` (richiesto dal check CSRF di Astro) → 302 + cookie
|
|
`session` (flag `Secure`, quindi passato manualmente negli header successivi visto che il server gira su http
|
|
in locale).
|
|
3. **Attivazione tag**: POST `/api/admin/showtags {"on":true}` con cookie di sessione → 200, cookie `showtags=1`
|
|
impostato.
|
|
4. **Pagina con showtags attivo**: GET `/` con cookie `session` + `showtags=1` → il body contiene:
|
|
- `tag-modal` (14 occorrenze: markup + CSS + script)
|
|
- `tag-badge__edit` (classe pulsante matita)
|
|
- `STYLE_GROUPS` (oggetto opzioni di stile nello script inline)
|
|
- 111 elementi con `data-tag`
|
|
5. **Ciclo GET→PUT identico a quello del modal**: preso un tag reale dal DOM (`home.hero.title-line-1`):
|
|
- `GET /api/admin/content/home.hero.title-line-1` → 200, JSON con `{tag, guid, type:"text", value, styleOptions}`
|
|
— esattamente la forma consumata da `openModal()`.
|
|
- `PUT` con nuovo `value` → 200, `{ok:true, value:"PERFORMANCE-TEST-EDIT."}`.
|
|
- Rilettura via GET → valore effettivamente cambiato in DB.
|
|
- `PUT` di ripristino al valore originale (`"PERFORMANCE."`) → 200, verificato con GET finale che il valore
|
|
originale è tornato. Nessun dato di produzione lasciato alterato.
|
|
6. Server fermato (`fuser -k 4399/tcp`) a fine verifica.
|
|
|
|
### Cosa NON è stato verificato
|
|
|
|
- Non ho un browser headless disponibile in questo ambiente, quindi **non ho eseguito il JS del badge/modal nel
|
|
DOM reale** (creazione dinamica dei badge posizionati, apertura modal via click, aggiornamento in-place del
|
|
testo senza reload, upload/rimozione immagine, comportamento dei `<select>` di stile). Ho verificato che lo
|
|
script sorgente sia presente e sintatticamente corretto (build Astro non fallisce, contiene le funzioni
|
|
`openModal`/`closeModal`/listener `tm-save`) e che le API che il modal chiama rispondano nel formato atteso
|
|
(GET/PUT verificati manualmente sopra). Il percorso "clic reale su ✎ → modal si apre → salvo → testo cambia
|
|
senza reload" resta da confermare in un browser vero.
|
|
- Non ho testato il ramo immagine (`POST`/`DELETE /api/admin/content/[tag]/image`) end-to-end nel modal, solo
|
|
che gli endpoint esistono da task precedenti.
|
|
|
|
## Commit
|
|
|
|
`git commit -m "feat(inline): badge con guid + modal di modifica contenuti in pagina"` su
|
|
`src/layouts/Base.astro`.
|