Vai al contenuto

Audit Compila V3 RAS - 2026-08-01

Sintesi

Compila V3 per il documento demo RAS e' raggiungibile e i test mirati passano. Durante l'audit e' stato trovato e corretto un bug backend sull'identita' delle foto: alcuni passaggi server distinguevano le foto solo per key + domanda, mentre il runtime V3 deve distinguere anche photoOrdinal. Questo poteva spiegare comportamenti come una foto specifica che non andava in parcheggio o veniva deduplicata in modo errato. Il runtime V3 ora applica anche un limite di 4 foto visualizzate/associate per singola domanda; il frontend blocca nuove destinazioni o upload diretti quando la domanda e' gia' piena.

Link demo:

  • https://safeops.nxt-sense.eu/dynamic/compila-v3/7176

Stato Del Servizio

  • safeops-web.service: active
  • Route V3 locale con host corretto:
  • GET /dynamic/compila-v3/7176
  • risultato non autenticato: 302 verso login
  • esito atteso: la pagina e' protetta da sessione
  • Asset statici V3 serviti correttamente con host safeops.nxt-sense.eu:
  • compila_v3_state.js: 200, 1479 byte
  • compila_v3_api.js: 200, 4961 byte
  • compila_v3_presets.js: 200, 10715 byte
  • compila_v3_profiles.js: 200, 747 byte
  • compila_v3_media.js: 200, 4960 byte
  • compila_v3_edit.js: 200, 5549 byte
  • compila_v3_render.js: 200, 26830 byte
  • compila_v3_map.js: 200, 4254 byte
  • compila_v3_app.js: 200, 73563 byte
  • compila_v3.css: 200, 29104 byte

Nota: un batch shell unico di curl ha dato 000 per restrizione/transitorieta' del sandbox; le richieste singole sugli stessi asset sono passate.

Test Eseguiti

Python

Comando:

pytest -q tests/test_compila_v3_runtime.py

Risultato:

  • 27 passed
  • warning non bloccanti: compatibilita' requests/urllib3, deprecazione PyPDF2

Comando:

pytest -q tests/test_compila_v3_runtime.py tests/test_dynamic_gallery_answer_normalization.py tests/test_ras_gallery_print_adapter.py tests/test_ras_gallery_vertical_renderer.py

Risultato:

  • 50 passed
  • stessi warning non bloccanti

JavaScript

Comando:

node --check app/static/ras/compila_v3_state.js app/static/ras/compila_v3_api.js app/static/ras/compila_v3_presets.js app/static/ras/compila_v3_profiles.js app/static/ras/compila_v3_media.js app/static/ras/compila_v3_edit.js app/static/ras/compila_v3_render.js app/static/ras/compila_v3_map.js app/static/ras/compila_v3_app.js

Risultato:

  • sintassi JS ok

Comandi:

node tests/js/compila_v3_api.test.js
node tests/js/compila_v3_media.test.js
node tests/js/compila_v3_presets.test.js
node tests/js/compila_v3_edit.test.js
node tests/js/compila_v3_map.test.js

Risultato:

  • tutti passati

Stato Dati Documento Demo 7176

Query eseguita con contesto applicativo SafeOps e accesso MySQL locale.

  • Documento 7176: presente
  • Parcheggio V3: 9 elementi
  • Cestino V3: 2 elementi

Elementi parcheggio rilevati:

# Key Domanda Origine Ordinale Target Stato
1 legacy-dynamic/ee13a9bfaf524050a49ff924cee8a63a.jpg __parking__ vuoto sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne vuoto
2 legacy-dynamic/f60ca209979e4ee2806b6c1a6a781fb1.jpg __parking__ vuoto vuoto vuoto
3 legacy-dynamic/64fc44bbe0184b0a9d643fa5ba6d27b1.png sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne vuoto sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne vuoto
4 legacy-dynamic/64fc44bbe0184b0a9d643fa5ba6d27b1.png sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne 4 vuoto vuoto
5 legacy-dynamic/ee13a9bfaf524050a49ff924cee8a63a.jpg sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne 3 vuoto vuoto
6 legacy-dynamic/4dc56539dbe34aaeabcc711dcec2bbc6.jpg sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne 2 vuoto vuoto
7 legacy-dynamic/80edca521ff94311b86992022a649bcd.jpg sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne 1 vuoto vuoto
8 legacy-dynamic/ca4437a9b9e949e2a297a048e7e954ba.jpg sec_aree_verdi_8__sono_presenti_aree_verdi_comuni_esterne 0 vuoto vuoto
9 legacy-dynamic/f60ca209979e4ee2806b6c1a6a781fb1.jpg vuoto vuoto vuoto vuoto

Elementi cestino rilevati:

# Key Domanda Origine Ordinale Stato
1 local:compila-v3:1785572219607:cb1d23665e6b __parking__ vuoto deleted
2 local:compila-v3:1785572237712:1d31c7b8aebc28 __parking__ vuoto deleted

Osservazione: esistono record vecchi senza photoOrdinal e record nuovi con photoOrdinal. La correzione mantiene compatibilita' con entrambi, ma per i test manuali successivi conviene pulire o isolare il documento demo se si vuole una baseline perfetta.

Correzione Applicata Durante L'Audit

File modificati:

  • app/modules/documentale/views.py
  • tests/test_compila_v3_runtime.py

Contratto corretto:

  • le foto in V3 sono identificate da key + questionId + photoOrdinal
  • quando photoOrdinal manca, resta valida la compatibilita' legacy key + questionId
  • il parcheggio verso una domanda non deve perdere l'ordinale
  • il cestino deve poter nascondere solo la foto con ordinale specifico
  • l'indice media non deve deduplicare due foto con stessa key ma ordinale diverso
  • il controllo permessi del cestino deve rilevare rimozione/eliminazione anche quando cambia solo photoOrdinal
  • ogni domanda V3 espone al massimo 4 foto; l'inventario globale resta disponibile per gestione e pulizia
  • il frontend avvisa e blocca quando si prova ad assegnare o caricare altre foto su una domanda gia' a 4

Nuovi test aggiunti:

  • due foto con stessa key e ordinale diverso restano entrambe visibili quando parcheggiate sulla stessa domanda
  • il cestino con identita' completa key::questionId::photoOrdinal nasconde solo la foto corretta
  • la rimozione dal cestino di un solo ordinale viene rilevata come cambio protetto
  • l'eliminazione definitiva di un solo ordinale viene rilevata come cambio protetto
  • una domanda con piu' di 4 foto viene limitata a photo_count = 4
  • il parcheggio non puo' far superare 4 foto associate alla stessa domanda

Funzionalita' V3 Verificate

  • caricamento pagina V3 protetto da login
  • asset modulari V3 serviti, senza file monolitico nuovo
  • test runtime risposta/foto/parcheggio/cestino passati
  • test JS API/media/preset/edit/map passati
  • note foto telefono presenti nella sanitizzazione parcheggio
  • coordinate GPS e metadati cattura presenti nella sanitizzazione parcheggio
  • modale OSM coperto da test JS
  • compatibilita' tra record legacy senza ordinale e record nuovi con ordinale

Rischi Residui

  • Non e' stato eseguito un test browser autenticato end-to-end su sessione reale.
  • Il documento 7176 contiene dati misti da prove precedenti: 9 parcheggio, 2 cestino, alcuni record senza ordinale.
  • La parita' con il vecchio Compila non e' completa per definizione: V3 e' una riscrittura modulare e va allineato per matrice funzionale, non copiando il monolite storico.
  • Il test automatico non ha ancora verificato screenshot mobile/desktop con thumb reali dopo login.

Prossimi Test Consigliati

  1. Test manuale autenticato su 7176 dopo refresh forzato:
  2. aprire https://safeops.nxt-sense.eu/dynamic/compila-v3/7176
  3. verificare se le 9 righe parcheggio sono coerenti o se conviene pulire la baseline
  4. provare parcheggio singolo delle foto ordinali 0, 1, 2, 3, 4
  5. verificare che la foto 4 risponda al bottone parcheggio
  6. Test cestino/ripristino:
  7. spostare una foto con ordinale specifico nel cestino
  8. ripristinarla
  9. ricaricare la pagina
  10. verificare che non spariscano thumb diverse con stessa key
  11. Test posizione:
  12. acquisire posizione
  13. ripetere acquisizione
  14. verificare conferma cancellazione vecchio punto e vecchia data
  15. aprire modale OSM
  16. Test mobile:
  17. controllare layout dei tre bottoni in parcheggio
  18. controllare collapse di parcheggio e lista foto
  19. controllare thumb e modale mappa su viewport telefono