Closed Bug 445736 Opened 16 years ago Closed 16 years ago

Wcap event/non-server attendee -> organizer gets no Update button in reply mail

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: andreas.treumann, Assigned: dbo)

Details

Attachments

(1 file, 1 obsolete file)

STEPS TO REPRODUCE:
===================

- use a WCAP calendar and create an event
- invite someone who has no account on this server (may ba a privat eMail adress)
- the attendee should accept this event and send the Reply eMail to the organizer

RESULT:
=======

- the organizer gets a Reply email without an 'Update' button


EXPECTED RESULT:
================

- the organizer gets a Reply email with an 'Update' button 

REPRODUCIBLE:
=============

- always
Flags: wanted-calendar0.9?
The cause seems to be that REPLY's DTSTAMP check fails:
<http://mxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/imip-bar.js#236>

I suspect the problem is that on ics parsing, new DTSTAMPS are created instead of using the persistent one:
<http://mxr.mozilla.org/mozilla1.8/source/calendar/base/src/calItemBase.js#741>

This looks wrong to me.
Flags: wanted-calendar0.9? → blocking-calendar0.9+
Whiteboard: [needs patch]
It seems to be a little different. The WCAP server always returns an updated DTSTAMP, even though there haven't been changes to the item. The REPLY's DTSTAMP is checked against the stored DTSTAMP which always fails then.
Assignee: nobody → daniel.boelzle
As far as I see, there's no chance to reasonably implement iTIP REPLY checks. The server always returns fresh DTSTAMPs which we currently check against. Even though the correct way to implement REPLY checks is to store REPLY stamps/sequence numbers for each attendee (see <http://rfc.net/rfc2446.html#s2.1.5>, and e.g. <http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-04#section-7>), there's no way to add further parameters along with &attendee=, e.g. like RECEIVED-DTSTAMP.
Attached patch disable revision checks for wcap (obsolete) — Splinter Review
This patch introduces a calendar property (set by wcap) to disable revision checks on iTIP messages. This would always offer the update resp. add/decline/tentative buttons for wcap calendars even though a REQUEST or REPLY has already been processed. I think it's just better than no options at all.

Further more I think I've found another small bug on SEQUENCE/MS-CDO-SEQUENCE fallback code, although I am not sure whether it's been introduced by intention. That change has landed with bug 361635 (patch https://bugzilla.mozilla.org/attachment.cgi?id=306790).
Attachment #336046 - Flags: review?(ctalbert)
Comment on attachment 336046 [details] [diff] [review]
disable revision checks for wcap

more precisely the latter paragraph is about the following code:

> function processRequestMsg() {
...
>     // 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 newSequence = itemList[0].getProperty("SEQUENCE");
>-
>-    // Make sure we don't have a pre Outlook 2007 appointment, but if we do
>-    // use Microsoft's Sequence number. I <3 MS
>-    if ((newSequence == "0") &&
>-        itemList[0].hasProperty("X-MICROSOFT-CDO-APPT-SEQUENCE")) {
>-        newSequence = itemList[0].getProperty("X-MICROSOFT-CDO-APPT-SEQUENCE");
>-    }
>+    var newSequence = calItipGetSequence(itemList[0]);
> 
>     var onFindItemListener = {
...
>         onGetResult:
>         function ogr(aCalendar, aStatus, aItemType, aDetail, aCount, aItems) {
>             if (aCount && aItems[0] && !this.processedId) {
>                 this.processedId = true;
>-                var existingSequence = aItems[0].getProperty("SEQUENCE");
>-
>-                // Handle the microsoftism foolishness
>-                if ((existingSequence == "0") &&
>-                    itemList[0].hasProperty("X-MICROSOFT-CDO-APPT-SEQUENCE")) {
This checks whether the iTIP message's item has the MS prop, but then reads it out of the calendar'item. Is this just a typo?

>-                    existingSequence = aItems[0].getProperty("X-MICROSOFT-CDO-APPT-SEQUENCE");
I think I should refrain to do further changes this late in the game, thus I've removed the before mentioned changes to sequence handling.
Attachment #336046 - Attachment is obsolete: true
Attachment #336325 - Flags: review?(philipp)
Attachment #336046 - Flags: review?(ctalbert)
Comment on attachment 336325 [details] [diff] [review]
disable revision checks for wcap - v2

Please document itip.disableRevisionChecks in the interface.

r=philipp
Attachment #336325 - Flags: review?(philipp) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.

No revision checks for WCAP; all iTIP/iMIP messages will appear to offer update/add/deny etc, even though a message has been processed already.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs patch]
Target Milestone: --- → 0.9
(In reply to comment #7)
> (From update of attachment 336325 [details] [diff] [review])
> Please document itip.disableRevisionChecks in the interface.
done
checked in lightning build 2008090205 -> VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.