404179 - Issue with remote calendars and undecided/unaccepted meetings with Zimbra.

Status: RESOLVED DUPLICATE of bug 273279

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

Description

[Gerald]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: TB 2.0.0.9 with Lightning .7 or .8pre

A meeting will populate in the Lightning calendar when refreshed because it appears in the Zimbra Collaborative Suite as an meeting invite in that time slot, which causes concern as you haven't actually accepted it.  It would be helpful if undecided/unaccepted meetings were shaded or otherwise noticeable and have options to accept or decline from the calendar.  Otherwise, unaccepted meetings probably shouldn't populate in the Lightning calendar.

Reproducible: Always

Steps to Reproduce:
1.Someone proposes meeting in TB and the meeting is updated to the ZCS server
2.You receive the meeting request email, but don't react yet
3.Synch your remote calendar and the meeting is in Lightning
Actual Results:  
Unaccepted/undecided meeting syncs to Lightning calendar as a meeting from Zimbra server.

Expected Results:  
Would be best to either be different shade/color and have accept/decline options in Lightning, or not sync until accepted.

Comment 1

[Gerald]

This also causes the issue reported in bug 361635:

https://bugzilla.mozilla.org/show_bug.cgi?id=361635

Once the unaccepted meeting populates in your calendar, you cannot accept the meeting via the email notification.  You get the error about a duplicate ID.

Invitation could not be processed.  Details: ID already exists for addItem

Comment 2

[Sven Giermann]

(In reply to comment #1)
> This also causes the issue reported in bug 361635:

Yes, setting this to depend on bug 361635.
Also bug 404900 (together with bug 361635) would at least give an ability to decline the meeting.
As both bugs don't handle the proposed shadow, I'm not setting this one to be a duplicate - but it would definitely be easier to resolve this issue after the mentioned bugs.

Comment 3

[Martin Schröder [:mschroeder]]

Gerald, do you still see this issue with Lightning 0.9?

Comment 4

[quan_tony]

I can confirm that this bug is still there in Lightning 0.9.  One way to work around it is to disable the setting which automatically refreshes calendars by setting calendar.autorefresh.enabled to false.  This forces users to manually refresh though to pick up changes if they use clients other than Lightning to edit events.