Files
smartbooking/features/visualizzazione-prenotazioni.md
Simone Bierti b4d0ca4898 Add ROLE_INCARICATO, configure mail, and add booking visualization specs
- Add ROLE_INCARICATO authority (AuthoritiesConstants, authority.csv)
- Configure SMTP mail settings for dev and prod environments
- Add faIdCard icon to FontAwesome config
- Add feature spec for booking visualization and management by role

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-11 15:48:02 +02:00

3.6 KiB

Ecco una bozza di specifiche tecniche strutturate in Markdown, ottimizzate per essere interpretate da un agente di coding (come un plugin IDE o un modello LLM focalizzato sullo sviluppo).


Specifiche Tecniche: Gestione e Visualizzazione Prenotazioni

1. Obiettivo

Implementare un sistema di visualizzazione e gestione delle prenotazioni basato sui ruoli utente (ROLE_USER, ROLE_INCARICATO), con logica di business legata all'esistenza di un oggetto Conferma correlato.

2. Modello Dati e Relazioni

  • Prenotazione (P): Entità principale.
  • Conferma (C): Entità correlata a Prenotazione.
    • Relazione: One-to-One.
    • Chiave Primaria: C.id deve coincidere con P.id.
    • Campi Conferma:
      • tipoConferma (Enum: TipoConferma)
      • motivoConferma (String/Text)
      • codice (String, Alfanumerico Base62, generato dal sistema).

3. Logica di Accesso e Visualizzazione

3.1 Vista: ROLE_USER

L'utente visualizza esclusivamente le proprie prenotazioni.

  • Query: SELECT * FROM Prenotazione WHERE utente_id = :current_user_id ORDER BY data_inserimento DESC.
  • Interfaccia (Tabella):
    • Caso A: Prenotazione SENZA Conferma
      • Azioni permesse: Visualizza, Modifica, Cancella.
    • Caso B: Prenotazione CON Conferma
      • Azioni permesse: Visualizza (Read-only), Visualizza Conferma.
      • Inibizione: I tasti Modifica e Cancella devono essere disabilitati o nascosti.

3.2 Vista: ROLE_INCARICATO

L'utente visualizza tutte le prenotazioni del sistema create negli ultimi 12 mesi.

  • Filtro Temporale: data_prenotazione >= CURRENT_DATE - 12 mesi.
  • Layout: Due tabelle distinte.

Tabella 1: Prenotazioni Pendenti (Senza Conferma)

  • Contenuto: Prenotazioni che non hanno un record corrispondente nella tabella Conferma.
  • Azioni:
    1. Visualizza: Apre il dettaglio della prenotazione.
    2. Prendi in carico: Apre una finestra modale (Pop-up).

Tabella 2: Prenotazioni Completate (Con Conferma)

  • Contenuto: Prenotazioni che hanno un record corrispondente nella tabella Conferma.
  • Azioni: Visualizzazione del dettaglio e della relativa conferma.

4. Workflow "Prendi in carico" (Modale)

Al clic sul pulsante nella Tabella 1 del ROLE_INCARICATO:

  1. Apertura Modale: Form di creazione per l'oggetto Conferma.
  2. Input Utente:
  • tipoConferma: Select box basata sull'Enum.
  • motivoConferma: TextArea (Testo libero).
  1. Logica di Sistema (Generazione Codice):
  • Il campo codice deve essere generato lato server (o pre-calcolato) convertendo il timestamp corrente (data/ora) in una stringa Base62 (caratteri 0-9, a-z, A-Z).
  1. Salvataggio:
  • Creazione record Conferma con id identico a quello della Prenotazione selezionata.
  1. Post-Azione:
  • Chiusura modale.
  • Refresh Reattivo: Le tabelle devono aggiornarsi senza ricaricare l'intera pagina (la prenotazione deve spostarsi dalla Tabella 1 alla Tabella 2).

5. Requisiti Tecnici Suggeriti

  • Sicurezza: Verificare l'authority lato server (Spring Security o equivalente) per ogni richiesta API. Non basarsi solo sull'occultamento dei tasti lato UI.
  • Generazione Base62: Implementare una funzione di encoding che trasformi long timestamp in String Base62.

6. Definizione del Successo (Criteri di Accettazione)

  • Un ROLE_USER non può cancellare una prenotazione se esiste una conferma.
  • Un ROLE_INCARICATO vede solo i dati degli ultimi 12 mesi.
  • Il salvataggio di una conferma sposta istantaneamente la riga tra le due tabelle dell'incaricato.
  • Il codice della conferma è univoco e generato in Base62.