693981 - Hitting update on an accepted invitation fails with remote calendar on Zimbra

Status: RESOLVED WORKSFORME

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

Description

[Mark Banner (:standard8)]

STR:

1) Send out invites using Lightning to an event that'll be stored in a remote calendar (zimbra).
2) Wait for someone to respond with an accepted response (in this case generated by zimbra).
3) View the response, see that there's an Update button to update the event, and hit it.

Actual results:

A dialog containing:

"An error occurred when writing to the calendar <name>!"

The details show:

Error code: MODIFICATION_FAILED
Description: Status Code: 409, Resource conflict.

The error console shows:

Error: An error occurred when writing to the calendar Work! Error code: MODIFICATION_FAILED. Description: Status Code: 409, Resource conflict.

Source File: resource://calendar/modules/calUtils.jsm -> file:///Users/mark/Library/Thunderbird/Profiles/9uumlyqg.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Line: 1101



Expected results:

No errors.


It is repeatable with the same email. If I look in the Lightning view of the entry, there's no indication of accepted or otherwise. If I did around in Zimbra web interface, then the status is accepted.

So really it looks like Zimbra has already processed the event and lightning should detect that and just ignore the accepted email or just say it has already been processed (I'm not sure why status=accepted emails wouldn't just be processed anyway).

This could be related to bug 459689, though I'd say its unclear at the moment.

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

I can image whats happening here, yes. This should be fixed by bug 670916, as a workaround you can set itip.disableRevisionChecks as a property for the calendar (pref calendar.registry.{uuid}.itip.disableRevisionChecks = true)

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

Does this error still exist? Please check again with Tb8 and Lightning 1.0

Comment 3

[Mark Banner (:standard8)]

This seems to be fixed well enough now.