357180 - Add support for cancelled ITIP/IMIP invitation

Status: VERIFIED DUPLICATE of bug 421886

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[Matp75]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Thunderbird 1.5.0.7(20060909) ligthning (2006100618)

it seems Lightning does not handle correctly cancelling an invitation

Reproducible: Always

Steps to Reproduce:
1.Send an invitation from Outlook
2.Cancel it from Outlook 
3.Receive it in ligthning

Actual Results:  
invitation is shown
Ligthning ask to add the invitation
a new invitation is added with cancel : title (localized)


Expected Results:  
Ligthning should ask to remove the existing invitation (or handle the case when there is no invitation to cancel)

original invitation can be seen in bug 357172 and bug 357175

Comment 1

[Matp75]

Attachment: cancel invitation (mail) from Outlook 2003 FR

Comment 2

[Matp75]

Attachment: Screenshot of the cancel invitation

Comment 3

[Matp75]

with last versions, behaviour is better (no more duplicate event creation) but support for cancelling invitation is still incomplete.

Comment 4

[Richard van den Berg]

Using Lightning 0.7, when I receive a cancellation from Outlook, I see: "This message contains an event that this version of Lightning cannot process." and I don't have any options to cancel or delete the meeting.

The meeting.ics Outlook sends looks like:

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT -0700 (Standard) / GMT -0600 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20071204T081024Z
[truncated]

Comment 5

[Simon Paquet [:sipaq]]

Please do not set the wanted0.8+ flag. Only release drivers are allowed to do this.

Comment 6

[Matp75]

Updating summary to better subject

Comment 8

[Hubert FONGARNAND]

i've begin implementation 

on https://bugzilla.mozilla.org/show_bug.cgi?id=361635

Comment 9

[Hubert FONGARNAND]

Attachment: reply/cancel patch v1.4

reply/cancel patch v1.4 coming from bug #361635

with formatting suggestions applied, the caldav part is
now in bug https://bugzilla.mozilla.org/show_bug.cgi?id=430280

Comment 10

[Daniel Boelzle [:dbo]]

Comment on attachment 317294 [details] [diff] [review]
reply/cancel patch v1.4

I don't see anything obvious wrong from a RFC2446 POV.

Apart from that, my drive-by comments:

>Index: base/src/calUtils.js
...
>+function getCompositeCalendar() {

Please don't add this to calUtils.js. There's already the same function in calendar-management.js and this name is widely used to determine 'the' composite calendar, i.e. the composite calendar having the currently visible calendars, not all calendars.
IMO it makes sense to have something like

function makeCompositeCalendar(<array_of_calendars>), so one could call it like

makeCompositeCalendar(getCalendarManager().getCalendars({}))

but this is just personal preference. Moreover, please leave it out of calUtils.js and add it only to imip-bar.js, because it's only used there.

>+    var onFindItemListener = {
>+        processedId: null,
>+        onOperationComplete:
>+        function ooc(aCalendar, aStatus, aOperationType, aId, aDetail) {
>+            if (!this.processedId) {
>+                // Then the ID doesn't exist, don't call us twice
>+                this.processedId = true;
>+            }
>+        },
>+
>+        onGetResult:
>+        function ogr(aCalendar, aStatus, aItemType, aDetail, aCount, aItems) {
>+            if (aCount && aItems[0] && !this.processedId) {
>+                this.processedId = true;
>+               // We have found an item
>+               gCalItemFound = aItems[0];
>+               displayCancel();
>+             }
>+        }
Could you cope with multiple replies? E.g. consider you've subscribed the calendar of another attendee. IMO it's safer if you just store references to the returned items on the listener object and actually set gCalItemfound, call displayCancel in onOperationComplete.

>+    // Per iTIP spec (new Draft 4), multiple items in an iTIP message MUST have
>+    // same ID, this simplifies our searching, we can just look for Item[0].id
>+    var itemList = gItipItem.getItemList({ });
>+    var itipItemDate = itemList[0].stampTime;
>+    // check if ITIP DTSTAMP is in the future
>+    var nowDate = jsDateToDateTime(new Date());
>+    if (itipItemDate.compare(nowDate) > 0)
>+        itipItemDate =  nowDate;
Why do you limit the item's DTSTAMP?

>+function displayReply(itipItemDate, existingItemDate) {
>+    //Verify that the item has ever been updated...
>+    if (itipItemDate.compare(existingItemDate) > 0) {

IMO it's cleaner to do this check prior to calling displayReply, move it to the listener code.

>+function deleteItemFromCancel() {
...
>+        var itemArray = gItipItem.getItemList({ });
>+        var itipItem = itemArray[0];
>+        if (itipItem.id == gCalItemFound.id) {
Why is this check necessary?

The following hunks look like they don't relate to this bug (which already covers both cancel and reply), or do I miss anything?

>@@ -512,16 +686,18 @@ function displayRequestMethod(updateValu
>                 description.firstChild.data = ltnGetString("lightning",
>                                                            "imipBarAlreadyAddedText");
>             }
> 
>             var button = document.getElementById("imip-button1");
>             button.setAttribute("hidden", "true");
>             button = document.getElementById("imip-button2");
>             button.setAttribute("hidden", "true");
>+            button = document.getElementById("imip-button3");
>+            button.setAttribute("hidden", "true");
>         } else {
>             // Legitimate update, let's offer the update path
>             if (description.firstChild.data) {
>                 description.firstChild.data = ltnGetString("lightning",
>                                                            "imipBarUpdateText");
>              }
> 
>             var button = document.getElementById("imip-button1");
>@@ -533,16 +709,23 @@ function displayRequestMethod(updateValu
> 
>             // Create a DECLINE button (user chooses not to attend the updated event)
>             button = document.getElementById("imip-button2");
>             button.removeAttribute("hidden");
>             button.setAttribute("label", ltnGetString("lightning",
>                                                       "imipDeclineInvitation.label"));
>             button.setAttribute("oncommand",
>                                 "setAttendeeResponse('DECLINED', 'CONFIRMED');");
>+            // Create a ACCEPT TENTATIVE button
>+            button = document.getElementById("imip-button3");
>+            button.removeAttribute("hidden");
>+            button.setAttribute("label", ltnGetString("lightning",
>+                                                      "imipAcceptTentativeInvitation.label"));
>+            button.setAttribute("oncommand",
>+                                "setAttendeeResponse('TENTATIVE', 'CONFIRMED');");
>         }
>     } else {
>         if (description.firstChild.data) {
>             description.firstChild.data = ltnGetString("lightning",
>                                                        "imipBarRequestText");
>         }
> 
>         var button = document.getElementById("imip-button1");
>@@ -554,10 +737,17 @@ function displayRequestMethod(updateValu
> 
>         // Create a DECLINE button
>         button = document.getElementById("imip-button2");
>         button.removeAttribute("hidden");
>         button.setAttribute("label", ltnGetString("lightning",
>                                                   "imipDeclineInvitation.label"));
>         button.setAttribute("oncommand",
>                             "setAttendeeResponse('DECLINED', 'CONFIRMED');");
>+        // Create a ACCEPT TENTATIVE button
>+        button = document.getElementById("imip-button3");
>+        button.removeAttribute("hidden");
>+        button.setAttribute("label", ltnGetString("lightning",
>+                                                  "imipAcceptTentativeInvitation.label"));
>+        button.setAttribute("oncommand",
>+                            "setAttendeeResponse('TENTATIVE', 'CONFIRMED');");
>     }
> }
>Index: locales/en-US/chrome/lightning/lightning.properties
...
>+imipAcceptTentativeInvitation.label=Tentative

After all, thank you Hubert. Your work is greatly appreciated; go on!

Comment 11

[Hubert FONGARNAND]

Attachment: reply/cancel patch v1.5

per review of Dbo

Comment 12

[Martin Schröder [:mschroeder]]

Hubert: Which bug is the one you want to push? It seems you want a single bug, either this one or bug 421886, for implementing REPLY and CANCEL for iTIP/iMIP. At the moment both bugs have the same patch attached (and an old version on a third one). Another alternative would be to split your patch up in a REPLY and a CANCEL part, and attach those patches to the corresponding bug report. Your choice. :)