[dev] Kronolith resources

[Michael Rubinsky]

I've committed an initial go at the resource work I've been doing on  
Kronolith to a 'kronolith_resources' branch in hatchery. I feel it's  
at the point where it could do with some more eyes looking at it to be  
sure there are no overt issues with the design that I am not seeing.

Most of the features are implemented, with the exception of the "group  
resources" - where a user could select a "Large Meeting Room" group  
and the first available meeting room in that group would accept.

For now, only horde admins may create/edit/delete actual resource  
calendars. These are managed similar to user calendars, through the  
"Manage Resource Calendars" link in the kronolith panel. Users may  
also use this link (renamed to just "Resource Calendars") to view a  
specific resource's calendar. Admins may directly create entries on a  
resource's calendar.

When resources are created, they may be set to either automatically  
accept/deny a request, accept/deny based on actual availability. A  
"manual" choice is also available, with the hope that some kind of  
iTip workflow could be used in the future, though I admit to having no  
idea how that could happen without resources having an actual user  
account (see below). Finally, there is also an option to ignore the  
request (response will be set to Kronolith::RESPONSE_NONE).

There is also a setting for the maximum number of conflicting  
reservations a resource can accept. Not sure if this level of detail  
is necessary, but thought it could be useful. If response type is set  
to Auto, a resource will automatically accept up to max_reservations  
number of over-bookings.

Resources are added to events, just like attendees via the  
attendees.php page. For now, I used a select list to choose them, but  
a more involved UI would be possible.  Currently the Response status  
is set to Accept/Deny initially _only_ if the resource is set to  
_always_ accept/deny. For response type of Auto, availability is  
checked when the event itself is saved, and a notification is pushed  
to indicate the response of any resources. In order to have even a  
tentative acceptance/denial before the event is saved, we would need  
to access the event form's form fields from the attendee popup.  
Doable, but was worried about issues syncing the two windows if the  
event time is changed after resources are added, but before the  
attendee window is closed.

Gunnar, could you take a look too and see what would be needed to make  
integrating this into kolab more likely? I'm honestly not sure how  
this would work with resources not having to be user accounts. Both  
specifically to Kolab, and in a more general sense in allowing the use  
of iTip notifications for resource request.  I suppose that if each  
resource had it's own email account (and corresponding horde account)  
the resource could be given an email address as it's identifier, then  
any iTip notifications would be send to the resources's email  
address...but that would require a user to login to horde as the  
resource to accept it, right?

Thoughts, opinions, flames??

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin