We have been working on a perl interface that does resource management in the backend, which can accept or reject events ( or resource bookings, if you will ) correctly. Currently there's manipulation of the email subsystem and obviously, caldav, involved - which works smoothly. This is based on the concept of a resource being a normal account, and is invited as a normal attendee. Employing the concept of shared calendar has NOT worked for us satisfactorily - especially if you have adamant and carefree ( careless ? ) users who can't be trusted to obey orders.
But, the bottom-line is, if your users have been used to other applications ( and I have only seen a particular propriety suite from Oracle ), then hacking the SOGo interface is the main part, or rather, something presently at least we need to work on. Eventually of course, integrating with the SOGo api ( the backend stuff, that is) would be awesome, but that would require some knowledge of the SOGo/SOPE frameworks ( written in obj c ). Regarding the UI, at a basic level, of course SOGo provides event conflict ( again, a resource booking conflict, that is) mechanism based on the freebusy information - but that is severely limited - taken in the context of resources. For normal attendees/users, its fine. So, the SOGo UI ( the attendee editor ) needs to take into account - a) complete freebusy information for that user/resource - not just for the day of event - which basically implies currently, only non-recurring events are taken care of. b) to be non-permissive in case of conflicts. This again, seems achievable by modifying the js code, but only for non-recurring events. c) to provide the user with the conflicting information in the interface ( in case of recurring events, obviously ), so that the user can change the timings accordingly. -- [email protected] https://inverse.ca/sogo/lists
