Last Comment Bug 827284 - REPLY and CANCEL messages do not forward itip item properties to the provider
: REPLY and CANCEL messages do not forward itip item properties to the provider
Status: RESOLVED FIXED
:
Product: Calendar
Classification: Client Software
Component: E-mail based Scheduling (iTIP/iMIP) (show other bugs)
: Lightning 2.2
: All All
: -- normal (vote)
: 2.3
Assigned To: Philipp Kewisch [:Fallen]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-07 04:58 PST by Philipp Kewisch [:Fallen]
Modified: 2013-02-07 11:06 PST (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Fix - v1 (3.31 KB, patch)
2013-01-16 11:46 PST, Philipp Kewisch [:Fallen]
matthew.mecca: review+
Details | Diff | Review

Description Philipp Kewisch [:Fallen] 2013-01-07 04:58:43 PST
Some providers need certain properties from the itip message on the modifyItem call for REPLY and CANCEL messages. For all other types, the full itip item is copied, but for these types the calendar item is just modified (participation status).

As a workaround, I propose to use a new provider property itip.copyProperties that returns an array of property names to copy. Patches coming soon.
Comment 1 Philipp Kewisch [:Fallen] 2013-01-16 11:46:03 PST
Created attachment 702952 [details] [diff] [review]
Fix - v1

I would love to add tests here, but we don't have any test framework for our itip code.

Then I could change the code to make that easier...and support the final itip rfc...http://memegenerator.net/instance/33487927
Comment 2 Matthew Mecca [:mmecca] 2013-01-18 20:14:00 PST
Comment on attachment 702952 [details] [diff] [review]
Fix - v1

Review of attachment 702952 [details] [diff] [review]:
-----------------------------------------------------------------

r=mmecca codewise.

::: calendar/base/modules/calItipUtils.jsm
@@ +848,5 @@
> +    let copyProps = item.calendar.getProperty("itip.copyProperties") || [];
> +    for each (let prop in copyProps) {
> +        if (prop == "METHOD") {
> +            // Special case, this copies over the received method
> +            item.setProperty("METHOD", itipItem.receivedMethod.toUpperCase());

Let's say I'm organizing an event, and create it in a calendar that requests the "METHOD" property, and invite an attendee. When the attendee replies and I update the item via the IMIP bar, it looks like the item ends up with a property "METHOD:REPLY". Is that what's intended?
Comment 3 Philipp Kewisch [:Fallen] 2013-02-07 08:21:59 PST
(In reply to Matthew Mecca [:mmecca] from comment #2)
> ::: calendar/base/modules/calItipUtils.jsm
> @@ +848,5 @@
> > +    let copyProps = item.calendar.getProperty("itip.copyProperties") || [];
> > +    for each (let prop in copyProps) {
> > +        if (prop == "METHOD") {
> > +            // Special case, this copies over the received method
> > +            item.setProperty("METHOD", itipItem.receivedMethod.toUpperCase());
> 
> Let's say I'm organizing an event, and create it in a calendar that requests
> the "METHOD" property, and invite an attendee. When the attendee replies and
> I update the item via the IMIP bar, it looks like the item ends up with a
> property "METHOD:REPLY". Is that what's intended?

Yes, thats whats intended. The reason I added this is that for certain providers it is indeed interesting if the item was added due to a REPLY/CANCEL or for other reasons. If the provider requests this, its up to the provider to handle it gracefully, for example by removing the property before replying with onAddItem/onModifyItem/etc.
Comment 4 Philipp Kewisch [:Fallen] 2013-02-07 08:23:48 PST
Pushed to comm-central changeset 1a75aaebea69

Note You need to log in before you can comment on or make changes to this bug.