= Gestione prenotazioni = Volendo permette di prenotare più di un'attrezzatura con un evento in agenda occorre, credo, aggiungere una '''nuova tabella''' al database (chiamata '''booking''', per esempio) con i seguenti campi: * '''bookingid''': chiave unica della tabella. * '''eventid''': id dell'evento in agenda che richiede la prenotazione. * '''equipmentid''': id dell'attrezzatura da prenotare. * '''approvedby''': utente che ha approvato la prenotazione, se l'attrazzatura non richiede approvazione delle prenotazioni, questo è l'id (login) dell'utente che ha effettuato la prenotazione (il campo fromuser del record calendar collegato). Quindi se un evento deve riservare più di un'attrezzatura ci saranno più record nella tabella booking relativi all'evento di agenda. Il tutto sta a '''verificare, al momento della registrazione''' di un evento che coinvolge una o più prenotazioni, che tali attrezzature non siano già impegnate nelle date o negli orari indicati... la difficoltà maggiore che vedo sta nella '''gestione delle ricorrenze'''. %green%27/08/07-'''Ale:'''%green% Si potrebbe imporre che le prenotazioni, se con ricorrenza, '''debbano avere un termine''' di fine ricorrenza. Si potrebbe adattare l' '''algoritmo''' utilizzato per calendar::yearly per creare un'elenco di occorrenze dell'evento che si sta inserendo/modificando e testare tutti gli eventi che coinvolgono la stessa risorsa per vedere se si intersecano. %blue%24.02.2008.Lucas: dobbiamo per forza gestire le ricorrenze anche nelle attrezzature? come posso approvare l'utilizzo ricorrente di una attrezzatura un eventuale imprevisto ne renderebbe impossibile l'utilizzo.%blue% %green%28/02/08-'''Ale:''' Io penso ad un caso semplice tipo "mi serve l'auto aziendale per tutta la settimana", in inserisco 5 eventi in calendario e chi deve approvare deve confermare 5 date. Preferirei avere la possibilità di inserirlo come ricorrenza. Potremmo decidere di limitare la selezione alla sola ricorrenza giornaliera e limitare il numero di giorni massimo di una prenotazione (31?).%green% Per ogni attrezzatura si può definire il '''gruppo''' degli utenti che '''possono prenotare''' l'attrezzatura (booking_group). Se non viene specificato, tutti gli utenti possono prenotare l'attrezzatura. %blue%Lucas:ok%blue% Per ogni attrezzatura si dovrebbe definire un '''gruppo''' di utenti che facciano da '''amministratori''' per tale risorsa (booking_admin_group), gli utenti appartenenti a questo gruppo possono, per così dire, ''requisire'' l'attrezzatura dalle prenotazioni: * l'amministratore dovrà dare un giustificazione; * questa giustificazione sarà allegata ad un ISMS di notifica che sarà inviata a tutti i partecipanti all'evento (vedi la ''Gestione inviti'' qui sotto). Opzionalmente è possibile definire, sempre per ogni attrezzatura, anche il '''gruppo''' degli utenti che devono '''approvare''' le prenotazioni (booking_approve_group). Si potrebbero generare dei messaggi isms per gli utenti appartenenti ai gruppi degli utenti che devono approvare le prenotazioni che ancora necessitano di approvazione. La query per visualizzare questi messaggi potrebbbe essere qualcosa di simile a: select * from booking join calendar on calendar.eventid = booking.eventid join equipments on equipments.id = booking.equipmentid join users_groups_link on users_groups_link.groupid = equipment.booking_approval_group and users_groups_link.uid = '$auth_user' where booking.approvedby = '' La '''query''' per visualizzare le '''prenotazioni di un utente''' dovrebbe essere qualcosa del tipo. select * from booking join calendar on calendar.eventid = booking.eventid join equipments on equipments.id = booking.equipmentid where calendar.touser = '$auth_user' and calendar.startdate >= oggi %blue%Lucas:daccordissimo sulle tre figure definite attraverso i gruppi all'interno della scheda delle attrezzature. Quindi: "Requisitori", "Prenotatori", "Approvatori". Ma per semplicità potremmo anche pensare di unire i Requisitori agli Approvatori e definirli Amministratori. Mi va bene l'una e l'altra soluzione%blue% Integrando il discorso degli '''inviti''', le prenotazioni dovrebbero essere legate solo ad eventi ''semplici'' (senza inviti) o agli eventi ''padre'', non agli eventi ''figli''. = Gestione inviti = 26/08/07-%green%'''Ale''': Innanzitutto dovrei chiarire con te cosa intendi per inviti...%green% Quello che ho in mente io è che, creando un'evento nel calendario (proprio o altrui), si possano aggiungere altre persone, le quali dovranno confermare o meno la loro partecipazione. 17/11/07-%blue%'''Lucas''': Ok ci siamo con la definizione. Certo tutto questo è un bel lavoro ma ne varrà la pena. Direi pero' di iniziarci a lavorare subito dopo il rilascio della 3.2.4.%blue% Se così fosse si potrebbero '''aggiungere due campi a calendar''': ;parent:id dell'evento ''padre'' questo lega un evento ad un evento principale. Per gli eventi normali questo campo non risulterà compilato. ;confirmation:flag a tre stati: * '''0=da confermare''': l'owner dell'evento figlio deve ancora confermare o meno la partecipazione all'evento * '''1=confermato''': l'owner dell'evento figlio ha confermato la partecipazione all'evento. * '''2=non confermato''': l'owner dell'evento figlio ha negato la partecipazione all'evento figlio. Per gli eventi figli (parent <> "") occorrerà applicare delle '''restrizioni''' ad alcuni campi della maschera di edit; i campi che dovrebbero essere bloccati sono (credo): data e ora, descrizione, ricorrenza, fine ricorrenza, tipo(?), categoria, riservatezza(?), contatto. Sia per un evento padre, che per un evento figlio, non dovrebbe essere possibile selezionare la checkbox ''visibile a tutti''. Come per i contatti principali e lo staff, così gli eventi figli dovrebbero poter essere creati solo '''dopo che l'evento padre è stato salvato''' (quindi ha un suo ID). Sia dall'evento padre che dagli eventi figli dev'essere possibile '''vedere lo stato di conferma''' o meno degli inviti e magari il campo '''note''' sia dell'evento padre che degli eventi figli, in questo modo è possibile instaurare una sorta di comunicazione tra l'invitante e gli invitati. Magari in una tab secondaria, tipo quella utilizzata per i todo. {| border=1 cellspacing=0 !Utente !Note !Conferma |- |'''Utente invitante''' |Note scritte dall'invitante |Confermato |- |Invitato 1 |Eventuali note dell'invitato 1 |Confermato |- |Invitato 2 | |Da confermare |- |Invitato 3 |Motivo per cui l'invitato 3 non ha accettato, ed eventuali altre proposte di data e orario. |Non confermato |} La data e l'ora devono essere '''modificabili solo dall'evento padre''', modificando o la data o l'ora tutti gli eventi figli dovrebbero ritornare in stato ''da confermare''. L'owner dell'evento padre deve poter '''aggiungere e togliere invitati''', togliendo un invito l'evento figlio viene cancellato (mandare anche un ISMS di avviso al ''disinvitato''?). L' '''owner dell'evento padre''' dovrebbe essere '''notificato con un ISMS''' per ogni '''risposta negativa''' all'invito. Tutti gli '''invitati''' dovrebbero essere '''notificati con un ISMS''': * quando l'invito viene creato; * quando viene modificato (per quanto riguarda data e ora); * quando tutti gli invitati hanno confermato l'invito.