Ciao Luca, credo tu abbia centrato l\'argomento, ma purtroppo non mi basta per risolvere.
Si è vero che dovrei lavorare sul calendario del Chair della reservation per riuscire a modificare un appuntamento, eliminarlo o crearne uno ex-novo.
Però ovviamente non potrò mai avere accesso ai calendari di tutte le utenze interne all\'azienda.
Da quanto ricordo e per quanto mi stanno confermando anche in altre realtà aziendali, lo standard per gestire le risorse e le reservation è appunto il Resource Reservation Database.
Ma questo RRDB purtroppo non espone le REST Calendar API e ho già visto che lavorare su questo DB con le DAS, manipolando i campi è un delirio.
Ho fatto qualche prova e riesco anche ad editare o cancellare un appuntamento, ma non lavorando nel contesto di un vero e proprio Calendar DB con API non di tipo Calendar, mi vado a perdere tutti i meccanismi di Controllo disponibilità orari, notifiche agli utenti e quant\'altro è insito all\'interno di una vera applicazione Calendar. Io non vorrei integrarmi in questo modo e anche da alcune ricerche in rete ho visto che è decisamente sconsigliato.
Se un cliente ha impostato la configurazione delle risorse tramite il Resource & Reservation DB è molto difficile convincerlo a cambiare configurazione.
Una possibilità che sto valutando è mettere in piedi un DB che funga da Shared Calendar condiviso per la prenotazione delle risorse.
Ho fatto un test in ambiente lab e funziona come concetto: creo uno Shared Calendar dal quale posso prenotare le risorse. Imposto eventualmente le Access Delegation su questo calendario condiviso.
Con una utenza qualsiasi accedo allo shared calendar e effettuo una reservation per una risorsa. La reservation creata viene correttamente notificata agli attendees e va a finire all\'interno del ResourseReservationDB. A questo punto però ho anche il calendario condiviso che mi contiene tutti gli appuntamenti e posso leggere e scrivere tramite REST Calendar API nel contesto di quel database.
Il Chair dell\'appuntamento però è lo Shared Calendar, non l\'utente che veramente ha prenotato tramite client Notes. E questo non mi piace per niente. Esiste un modo per preservare l\'utente che ha creaqto l\'appuntamento?
Anzichè farlo manualmente da client notes, provo quindi a inserire un nuovo appuntamento usando le Calendar API e riesco a creare l\'appuntamento mi sembra in modo corretto, ma non riesco a notificare a nessun l\'appuntamento e questo non va a finire nel Resourse e Reservation database. La risorsa quindi risulta ancora libera??? Qui spero bene sia colpa mia e che mi manchi qualcosa nella creazione dell\'appuntamento. Devo ancora indagare tecnicamente.
Vorrei capire come approcciare il problema: su altri sistemi come Exchange o Gmail ogni risorsa ha un proprio calendario con un indirizzo specifico e se voglio interagire con quei calendari è più semplice.
In Notes invece c\'è impostato quel Resource Reservation Database che mi complica parecchio la vita.
La soluzione ideale sarebbe questa: nei mail-in documents di ogni singola risorsa indico il proprio calendario dedicato, anzichè il Resorce Reservation DB. Quando un utente prenota una risorsa, l\'evento viene scritto nel calendario dedicato per quella risorsa.
E\' plausibile come soluzione? Ma un cliente che ha già inpostato il ResourceReservation DB per ogni risorsa accetterà mai di modificare questa configurazione?
Nel caso non abbia altre applicazioni di terze parti che lavorano sul RRDB, quali altri ostacoli potrebbe trovare nell\'adottare una soluzione del genere?
in definitiva : come ne esco? Ci sono altre soluzoni a parte quelle prospettate?
Grazie
|