Meeting Scheduling
The scheduling features of Bedework are almost complete; there is enough support to carry out simple scheduling. The flow of meeting requests and responses is defined by the relevant RFCs (2446, 2447) and the CalDAV scheduling extensions.
Calendar users and addresses
The potential attendees for a meeting may be internal to the system, that is they are Bedework users, or external. This is determined by their calendar user address (CUA) which looks like an email address. The Bedework system is identified by one or more email domains, for example cal.mysite.edu and an address in those domains is considered internal otherwise it is external.
For example, with the above domain, jim@cal.mysite.edu is internal, jim@thatsite.edu is external.
In addition, Bedework supports principals which look something like “/principals/resources/vcc311”. These are generally used to handle resources and locations but user principals are also mapped on to the email form of the calendar user address.
Bedework also allows the configuration option of preserving the domain part of a CUA. If we are not preserving the domain then a Bedework CUA of jim@cal.mysite.edujim@cal.mysite.eduwould map on to a Bedework user jim. For single domain systems this is more convenient.
Special Calendars: Inbox and Outbox
Each user has an inbox and an outbox. These are calendars with some special characteristics. Incoming scheduling requests always go to the inbox. They may arrive there via CalDAV, through uploading meeting requests or via an email interface. Scheduling responses to external users will go to the outbox. The may be immediately processed and at some point removed from the outbox.
To initiate a meeting request, use the add meeting link, add the attendees then continue on to set the details. Meeting requests must have one or more attendees and one originator (usually the current user) who will be added as an attendee.
The inbox and outbox will be created automatically when required. The actual names are configured during the build process so may be localized.
Incoming meeting requests will be placed in the default scheduling calendar: this can be configured in the user preferences of the personal web client. To respond to a meeting request, click on the event in the calendar.
Automatic processing
There are user preferences which indicate meeting requests can be automatically processed. If time is available for the incoming request it will be accepted, otherwise it will be declined. It is also possible to indicate that acceptances will be automatically processed; a meeting will have the attendee status updated automatically when the incoming response is an acceptance.
Scheduling resources
Bedework supports simple scheduling of resources. This is enabled with a degree of automatic processing of meeting requests to special resources. For example, if a room has the principal /principals/resources/vcc311 then that principal can be added as an attendee to a meeting which is intended to be in that room. The aggregated freebusy for the attendees will be displayed which includes the free time in that room.
The meeting request will be processed and added to the room's calendar, effectively booking the room for that period.
Special Calendars: Deleted
This is here to allow users to subscribe to a calendar to which the have only read access but still be able to 'delete' events they do not want to see. For example, a user may subscribe to a 'films' calendar and delete those they are not interested in. On deletion of such an event we add an entry to the deleted calendar which acts as a mask on retrieval.
Note that there is a fix in the stylesheets which hide the delete action if the subscription is marked unremovable. The assumption is that such subscriptions require that the events also be unremoveable. These subscriptions can be used fro class lists etc.