Child pages
  • Dev Status
Skip to end of metadata
Go to start of metadata

What we can do

Can create, read, update, and delete events for a range of test users: student01-student05, and instructor01-instructor05

Can automatically provision a new calendar when a worksite is accessed for the first time

Can communicate with Zimbra on behalf of someone who is not the calendar owner, i.e. students will see their course events (see "Caveats" below)

Can configure the system to use a default calendar name for the "My Workspace" calendar. Zimbra uses a default calendar called "Calendar" so we're configured to use Calendar for My Workspace events.

Can preserve the time zone of the Sakai server when new events are added and sent up to Zimbra

Can handle the longer event descriptions that had previously caused our ical4j parser to choke

Attachments are supported by adding Sakai URLs to the event description.

Can handle recurring events from Zimbra.

Can edit event recurrence in Sakai.

Caveats

There is no mapping between usernames in Sakai and the calendar system. Currently it assumes that your Sakai username is your enterprise calendar username.

There is no attempt to use a real enterprise calendar password. The passwords are hard-coded in a table.

The Sakai calendar tool cannot express event recurrence with the level of sophistication that Zimbra can, i.e., particular days of the week. If you edit the frequency of an event in Sakai that had been set up with this level of customization in Zimbra, the sophisticated version will be overwritten with the simplified version.

Not yet handling HTML descriptions UPDATE: Zimbra appears not to preserve formatting for event descriptions that come out. If this is not something configurable, there's no way to preserve HTML in a description. UPDATE: I have disabled rich text editors on the calendar pages. Still need to add a property that controls this.

Not yet preserving the Event Type field. UPDATE: Zimbra won't preserve an iCalendar XProperty for this field. Our options are to discard the Event Type or somehow encode the event title or description with the information. UPDATE: Tried using the standard iCalendar field "CATEGORIES" for this, and Zimbra doesn't preserve it either.

CalDAVCalendarService currently relies on the ID of the site creator to determine who is the owner of the calendar. This will not be the correct behavior if someone other than the course instructor (e.g. "admin") has created the site. (Note: we ought to be able to get the correct behavior by using the WebDAV access control protocol) UPDATE: we are now using an Access Control List, but it doesn't solve the problem because we still need a place to create the calendar in the first place, the calendar owner. We could have a special user in the calendar system who was the owner of every calendar, but then the instructor wouldn't have the benefit of seeing course calendars within Zimbra. Another option is to add a property to the Sakai site which names the site owner. This would have to be done at the point of worksite setup.

We explored various ways to get course events to show up for a student within Zimbra. Adding attendees to the iCalendar doesn't really help, because even then the attendee still needs to receive an invitation email for the even to show up on his calendar.

Status per-JIRA

(JIRA links go here)

Test Servers

Zimbra URL: http://ganymede.unicon.net/zimbra/

Sakai URL: http://sakai-caldav.unicon.net

  • No labels