Add documentation and enhance Conferma entity with QR code tracking
Some checks failed
Build and Publish / build (push) Failing after 48s
Some checks failed
Build and Publish / build (push) Failing after 48s
- Add Claude Code documentation (CLAUDE.md) with project overview and development commands - Add specialized agent configurations (spring-boot-engineer, vue3-frontend-engineer) - Add feature specifications (check liberatorie, configurazione disponibilità, profilo utente) - Enhance Conferma entity with codiceQrLink and presenzaConfermata fields - Update Liquibase changelog and test data for Conferma changes - Update frontend Conferma component and model with new tracking fields 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
11
features/check-liberatorie.md
Normal file
11
features/check-liberatorie.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# Check Liberatorie
|
||||
|
||||
## Contesto
|
||||
Quando un utente loggato al sistema intende inserire una nuova prenotazione il routing dell'applicaziione vue lo manda su "/prenotazione/nuova" attivando il componente @prenotazione-form-user.component.ts. Nel form che viene presentato all'utente, @prenotazione-form-user.vue ci sono delle sezioni:
|
||||
* una, con un form html, per inserire i dati della prenotazione (scegliere la struttura, giorno e ora d'inizio dell'evento per cui si prenota, giorno e ora di fine, il numero di partecipanti e le motivazioni per l'evento)
|
||||
* la seconda con un riepilogo delle informazioni dell'utente che sta eseguendo la prenotazione (se è un privato o se è una società)
|
||||
A questo punto dobbiamo estendere questa maschera per tenere conto del fatto che ogni struttura (selezionata nel form attraverso una select box) ha associati uno o più ModelliLiberatoria (@src/main/webapp/app/shared/model/modello-liberatoria.model.ts), che rappresenta delle informazioni che l'utente, che compila la prenotazione, deve accettare per poter inserire la prenotazione stessa.
|
||||
|
||||
## Da implementare
|
||||
è da implementare una nuova sezione dal titolo "Liberatorie". Qui dentro vanno recuperati gli oggetti Liberatoria (@src/main/webapp/app/shared/model/liberatoria.model.ts) associati all'UtenteApp e ModelloLiberatoria, a sua volta associato alla Struttura selezionata nel form di prenotazione. Nel caso in cui gli oggetti Liberatoria non esistessero, è necessario permettere all'utente di compilarli: vanno mostrati, per ognuno degli oggetti Liberatoria non presenti, dei link con il nome del ModelloLiberatoria da accettare; quando l'utente preme sul link si deve aprire una modale che nel corpo avrà le informazioni dell'oggetto ModelloLibreratoria da associare alla Liberatoria che stiamo accettando e un breve testo, che contenga i dati dell'utente del tipo "il sottoscritto {{utente.nome}} {{utente.cognome}} presa visione della documentazione proposta accetta le condizioni ivi indicate". La modale avrà poi 2 pulsanti "Accetta" e "annulla": accettando verrà lanciata la chiamata di salvataggio dell'oggetto Liberatoria con associati i riferimenti dell'UtenteApp e del ModelloLiberatoria. Il submit delle informazioni verrà completato inserendo nella proprietà "liberatoria.accettata" la data corrente.
|
||||
Contestuale alla risposta di avvenuto salvataggio da parte del backend verrà chiusa in automatico la modale e verrà aggiornata la sezione "Liberatorie" tenendo conto della presenza della nuova liberatoria inserita.
|
||||
26
features/configurazione_disponibilita.md
Normal file
26
features/configurazione_disponibilita.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Feature configurazione disponibilità struttura
|
||||
|
||||
## Contesto
|
||||
|
||||
Questa feature dell'applicazione permette agli utenti i ruoli di INCARICATO o ADMIN di accedere alla funzionalità di configurazione delle disponibilità (sia in apertura che in chiusura) di una determinata struttura. Grazie a queste "disponibilità" inserite sarà possibile, insieme alle prenotazioni già accettate per una determinata struttura, determinare l'ammissibilità di una certa prenotazione per suddetta struttura.
|
||||
|
||||
## Descrizione feature
|
||||
|
||||
L'utente loggato al quale è associato il ruolo di INCARICATO oppure di ADMIN ha la possibilità di accedere alla lista strutture inserite a sistema (come quella del componente @src/main/webapp/app/entities/struttura/struttura.vue). Nella tabella html che espone la lista va aggiunto un pulsante all'interno del "<div class="btn-group"></div>" con una icona font-awesome di un orologio che permetta di accedere alla maschera di visualizzazione e inserimento delle disponibilità della struttura indicata nella riga.
|
||||
La maschera sarà organizzata con in alto una sezione compatta con i dati della struttura (quelli del modello al file @src/main/webapp/app/shared/model/struttura.model.ts) non editabili. Al di sotto una sezione che contenga il form per l'inserimento di una disponibilità per la suddetta struttura. Il form (che tratterà i dati del modello @src/main/webapp/app/shared/model/disponibilita.model.ts) dovrà anch'esso essere organizzato per sezioni:
|
||||
* la prima sezione conterrà il dato TipoDisponibilità (visualizzato attraverso una select box prevalorizzata al dato CHIUSURA)
|
||||
* la seconda sezione conterrà i dati "oraInizio" e "oraFine" visualizzati sulla stessa riga. Questi determinano l'intervallo di temporale di validità della disponibilità che si sta inserendo
|
||||
* la terza sezione conterrà il campo "dataSpecifica" che indica una precisa collocazione temporale di una giornata per la quale si sta configurando la disponibilità (es: 25/12/2025). Accettiamo che possa essere vuoto.
|
||||
* la quarta sezione conterrà il dato "giornoSettimana" presentato con una select box senza valore prevalorizzato (accettiamo che possa essere vuoto)
|
||||
* infine una sezione per un campo "note"
|
||||
In fondo al form due pulsanti "Inserisci disponibilità" e "Annulla".
|
||||
|
||||
Come regola, è possibile eseguire il submit del form se i campi "TipoDisponibilita" e "oraInizio" e "oraFine" sono valorizzati. Inotre deve essere valorizzato in maniera alternativa (o uno o l'altro, non entrambi) o il campo "dataSpecifica" o la select box "giornoSettimana".
|
||||
Al submit del form viene inviata la chiamata all'endpoint di back-end per il salvataggio della dispobilitità per la struttura indicata.
|
||||
|
||||
Va realizzato anche un endopoint nell'API del back-end che permetta di eseguire una chiamata passando come parametri:
|
||||
* l'id di una struttura
|
||||
* data e ora di inizio
|
||||
* data e ora di fine
|
||||
(che saranno determinate nel form di inserimento nuova prenotazione)
|
||||
La logica di business recupererà per la struttura le prenotazioni già accettate e le disponibilità inserite valutando se le stesse date indicate nella chiamata non si sovrappongono ad una prenotazione accettata o cadono in una indisponibilità (disponibilità di tipo CHIUSURA) indicata per la struttura.
|
||||
11
features/profilo_utente.md
Normal file
11
features/profilo_utente.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# Feature gestione del profilo utente
|
||||
|
||||
## Contesto
|
||||
|
||||
L'utente che si registra all'applicazione attraverso l'endpoint "/api/register" crea un entità User (@src/main/java/it/sw/pa/comune/artegna/domain/User.java). Associata all'entità User con una relazione OneToOne c'è l'entità UtenteApp (@src/main/java/it/sw/pa/comune/artegna/domain/UtenteApp.java): questa entità contiene informazioni essenziali da inserire nella richiesta di prenotazione, quindi è necessario, anche se non obbligatorio, che l'utente, dopo la registrazione possa accedere ad una interfaccia nella quale inserire e modificare i propri dati dell'UtenteApp.
|
||||
|
||||
## Dettagli funzionalità
|
||||
|
||||
Per l'utente che ha completato la propria registrazione all'applicazione, va previsto un controllo sull'inserimento dei dati dell'entità UtenteApp associata al proprio User. Nel caso l'utente non abbia ancora inserito le informazioni dell'entità UtenteApp deve essergli proposta una interfaccia per completare il suo profilo con le informazioni richieste.L'interfaccia deve essere un form suddiviso in due diverse sezioni:
|
||||
* la prima sezione contiene i campi associati ai dati personali dell'utente: nome, cognome, data di nascita, luogo di nascita, residente, telefono; il campo username e email devono essere valorizzati dall'entità User (proprietà "internalUser") associata e devono essere campi disabilitati per questo form.
|
||||
* la seconda sezione, facoltativa, contiene le informazioni riguardo alla società o associazione per la quale l'utente intende operare le prenotazioni: nome società, sede, codice fiscale, telefono della società, email della società.
|
||||
Reference in New Issue
Block a user