Gestione prenotazioni e inviti in calendar (Bozza) (Documento scaduto)

Visualizza il documento in formato stampabile.

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.

27/08/07-Ale: 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.

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.

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?).

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. Lucas:ok

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

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

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-Ale: Innanzitutto dovrei chiarire con te cosa intendi per inviti...

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-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.

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.

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.