Created attachment 342903 [details] invitation message Standard8 sent out an iMIP invitation to a Tb3.0a3 post-mortem. Lightning claims that the event has already been added to my calendar, but, unfortunately, it hasn't. Attached is the message.
The thing that makes this bug particularly painful is that it doesn't seem to be possible to generate an iMIP reply to a message that's in this state.
Dan, are you sure its not in your MoMo calendar? So maybe I did something a bit nasty here: 1) Have a google calendar that more than one person subscribes to (and linked to from lightning). 2) Create an event on the google calendar and send out invites to some of those people who are subscribed to the google calendar. I've also seen that David Bienvenu accepted the invitation and now there's two events in google calendar. I think that's another bug I saw earlier, though I can't see it now.
Ah, it is indeed. I'm not subscribed to that Google calendar in this profile, so I suspect what happened is that the Zimbra server placed it in my calendar. Now, this is compounded by the fact that I'm having some other CalDAV problem interacting with the Zimbra server (which I'll file in the next day or so), so the event wasn't visible in Lightning. That said, even if the event had been visible in Lightning, the workflow here is confusing, so I think we probably need to figure out what the user-experience should be as well as how that matches with what's going on at the iMIP level.
Summary: Lightning claims iMIP item already added to calendar when it's not → same event arrive via iMIP handled both by Zimbra server & Lightning creates weird user-experience
Summary: same event arrive via iMIP handled both by Zimbra server & Lightning creates weird user-experience → same event arriving via iMIP handled both by Zimbra server & Lightning creates weird user-experience
It's not clear to me what's the real problem. Dan, could you please rephrase your problem? some comments: - We only take writable calendars into account for iTIP/iMIP, i.e. we assume people that could write a calendar run/own it. - IIRC a google specific problem is that you cannot preserve the UID when adding: the server always creates a new one; Philipp? - Dan, why is it in your Zimbra calendar, did you accept it before?
Part of the problem, I think, is not specific to Zimbra, but has to do with using two different user-agents to interact with the same iTIP invite, and one not necessarily knowing what the other has done. (In this case the agents were Lightning and the Zimbra Web UI). Unfortunately, I don't recall all the details here; next time it happens, I'll add more to this bug...
So the iTIP message has been consumed by Zimbra and put into the calendar. Lightning finds it and reports it has already been added which looks OK to me. Right?
Dan, could you confirm my last comment #6?
I can confirm comment 6; the weird thing about the user experience is this: the Zimbra web UI has the invite highlighted to show that it requires action, and it's possible for me to accept, decline, or mark it as tentative. The Lightning message view displays a message bar with the text "This message contains an event that has already been processed.", and the calendar view displays the event as though it were already confirmed. This means that someone using only Lightning would not realize that they need to take action to explicitly accept, decline, or as tentative in order to cause the other meeting attendees to be notified. Furthermore, Lightning isn't providing any way to actually take that action.
IMO it's correct that Lightning shows that the iMIP message has been consumed. What wonders me is that Zimbra seems to have *accepted* the invitation automatically. Could you please check that? In case of undecided invitations, the views show dotted/transparent event boxes.
Daniel, I've seen this problem with Zimbra and Lightning as well. Zimbra shows the event in this case as tentative, while lightning shows it as accepted. Further, as Dan indicated, there's no way in Lightning to accept/decline/make tentative these events, Bug 404179 is another bug describing what is basically this same symptom.
Sorry, but I won't find time for this in the foreseeable future.
Assignee: dbo.moz → nobody
I believe the priority on this should be a bit higher; if Lightning and another iMIP consumer (say, an iPhone or the Zimbra auto-accept feature) have already updated the event, Lightning doesn't just produce an error - that error appears to degrade Lightning functionality for some time, possibly until a Thunderbird restart. I don't think the functionality needs to change, just the error handling.
This seems to fit what we are seeing as well. Accept/decline messages seem to return to a actionable state after reading another message and going back to the iMIP. ie: It originally appears to be consumed but later is not.
Given there is now an "Open" button since the invitation is already processed, I think we can close this bug. If I am missing something, please reopen.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.