ai – Almost Intelligent

Time for an update on GSoC. In the last weeks i finished working on the delegation code and added the counter method as well.

Delegation:

After the work on the imip-bar was described in the earlier posts, the missing part is the event-summary-dialog. Especially when using caldav, this is the main entrypoint for delegation requests. I extended the dialog to hold up possible delegetation info and do the needed transactions with the caldav server.

This was followed by extensive tests between SOGo [1], Zimbra [2] and the Lightning in memory calendar implementations.

Finally i put some work into cosmetic updates, like additional informations for the imip template on delegation.

Counter:

The imip counter method had to be added from scratch. I startet again with the calItipUtils  module where the new methods “COUNTER” and “DECLINECOUNTER” were registered at various places.

Most effort was spend on a new dialog holding the nessassary informations and not adding to the already overloaded and overwhelming calendar-event-dialog files.

When the user changed the wanted time or location properties, a new COUNTER request is send to the organiser.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:COUNTER
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
      DTSTART:19970701T160000Z
      DTEND:19970701T170000Z
      DTSTAMP:19970612T190000Z
      SUMMARY:Discuss the Merits of the election results
      LOCATION:Blue Conference Room
      COMMENT:This time works much better and I think the big conference
       room is too big
      UID:calsrv.example.com-873970198738777a@example.com
      SEQUENCE:0
      END:VEVENT
      END:VCALENDAR

The organizer can either reject the request by sending a DECLINECOUNTER with the originial itip item back to the attendee or accept by sending a new REQUEST with updated sequence number.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:DECLINECOUNTER
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      COMMENT:Sorry, I cannot change this meeting time
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      DTSTAMP:19970614T190000Z
      END:VEVENT
      END:VCALENDAR

See RFC 5546 [3] for more information.

[1] SOGo - http://www.sogo.nu

[2] Zimbra - http://www.zimbra.com/

[3] RFC 5546 - http://tools.ietf.org/html/rfc5546#page-33

In the last weeks i worked on the implementation of the itip delegation method. The process is specified in rfc 2446 and describes the following steps:

1.) Create a reply to the organiser with the partstat of the attendee set to ‘delegate’ and add a new attendee.

2.) Set delegate-from and delegate-to parameters in the itip message.

3.) Send the replay message to the organiser and the original request to the delegate.

Here some example mails resulting from the steps above:

Response to the organiser:

BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
    TO="Mailto:E@example.com":Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

Invite delegate:

BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
    TO="Mailto:E@example.com":Mailto:C@example.com
   ATTENDEE;RSVP=TRUE;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   DTSTART:19970701T180000Z
   DTEND:19970701T200000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

Most of the changes where made in the calItipUtils.jsm:

First i added a check in the ItipFindItemListener.onOperationComplete function to add a callback for the delegation button being pressed. This will show up the imip-delegate-dialog where the user can pick the person he wants to delegate to. After this, the two itip mails are generated and send to the organiser and delegate.

Unfortunately i lost several days due to BUG 762854 which didn’t allow me to test the mail function at all. After this bug got fixed i could proceed with my implementation resulting in the delegate mails being generated correctly and send to the delegate and organiser.

The last remaining points to complete delegation support are correctly detecting the delegation update by the organiser, which will until now result in an unknown method exception and finding a way to save the state of the delegated event by the attendee to prevent the action buttons from being shown everytime the user looks at the invitation mail.

 imip-bar.js / imip-bar-overlay.xul:

The third button will now work as a menu-button, if there are more than 3 possible actions on a itip request. If there are exact 3 actions available, the button will drop its menu type and act as a normal button instead.

More than three actions:

Three actions:

Less then three actions:

imip-delegate-dialog.js/.xul:

After porting the dialog from the inverse source repository, the xul attributes had to be updated to gecko 1.9 attributes to get auto-completion working again.

With this, the immediate GUI updates required for the delegation support should be done and the missing functionality in calItipUtils.jsm will come next.