6.0.0-git
2024-03-19
Last Modified 2005-08-03 by Jan Schneider

Current methodology for sharing resources would involve having each resource be a share that an existing Horde user owns. Resources could be booked by including them as an attendee for an event.

My thinking is that people tend to view a person and a resource (such as a room, a mobile computer lab, etc.) as different items and for good reason. As a result, users will want to add people separately from how they add resources. As a result of that, there should be a distinction between the two when creating a new event. In addition, resources generally have other constraints to them. It should not be possible to double book a conference room, or to request that the same mobile computer lab be present in two different locations at once. Likewise, there is generally additional time needed before and after a meeting, to setup and tear down a room. So for scheduling purposes, it would be helpful to have a user-specified window before and after an event, that would tie up that resource as well.

There should also be some sort of automated processing of requests for resources as well (or at least provision for that). An organization could elect tohave a user approve all resource requests, in which case the current means of using a user-owned share for that resource would work (i.e. user processes iTip attachment for a resource request). However, that has drawbacks, as it requires timely response by a user, while resource scheduling is generally something you want to happen realtime. Also, a user may leave, change names, whatever, in which case the resource needs to be reassigned to someone else, which has to be done before that user's account is deleted. For that reason, I proposed the concept of a system share, which would be owned by Horde, accessible by default by a Horde Administrator, and extended to additional users by use of the Horde Permissions system (such that a normal user with appropriate permissions could also change resource allocation).

Free/Busy info could be extracted from the current Free/Busy page, with the addition of a new designation. Currently a designation of "u" returns a user's Free/Busy info, a designation of "c" returns the Free/Busy info for a share, and I'd propose a designation of "r" to return any additional constraints (such as setup/teardown time) that might be applied to a share. Essentialy "r" returns "c" + additional constraints.

So in summary:

  • each resource would correspond to a system-owned share,
  • each resource could have extensible time windows before and after, to allow for setup and teardown,
  • an automated but separate means to book resources, such that a user can select resources separately from people, submit a request, and that request is processed close to real-time by the system