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)
Calendar
E-mail based Scheduling (iTIP/iMIP)
Tracking
(Not tracked)
VERIFIED
FIXED
0.9
People
(Reporter: andreas.treumann, Assigned: dbo)
Details
Attachments
(1 file, 1 obsolete file)
5.84 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
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?
Assignee | ||
Comment 1•16 years ago
|
||
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+
Updated•16 years ago
|
Whiteboard: [needs patch]
Assignee | ||
Comment 2•16 years ago
|
||
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
Assignee | ||
Comment 3•16 years ago
|
||
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.
Assignee | ||
Comment 4•16 years ago
|
||
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)
Assignee | ||
Comment 5•16 years ago
|
||
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");
Assignee | ||
Comment 6•16 years ago
|
||
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 7•16 years ago
|
||
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+
Assignee | ||
Comment 8•16 years ago
|
||
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
Assignee | ||
Comment 9•16 years ago
|
||
(In reply to comment #7) > (From update of attachment 336325 [details] [diff] [review]) > Please document itip.disableRevisionChecks in the interface. done
Reporter | ||
Comment 10•16 years ago
|
||
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.
Description
•