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.
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 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?
(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.
Pushed to comm-central changeset 1a75aaebea69
or
