After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770434 - Meeting time changes result in duplicate meetings in the calendar
Meeting time changes result in duplicate meetings in the calendar
Status: RESOLVED OBSOLETE
Product: evolution-ews
Classification: Other
Component: Calendar
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-08-26 11:09 UTC by Robert Munteanu
Modified: 2021-05-19 11:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Events matching UID from Evolution's calendar storage (2.15 KB, text/calendar)
2016-08-31 08:34 UTC, Robert Munteanu
Details

Description Robert Munteanu 2016-08-26 11:09:03 UTC
The following steps resulted in duplicate meetings in the Evoultion calendar for me:

1. Receive invite for a meeting between 14:00 and 15:00
2. Accept meeting
3. Receive invite update, time changed to 14:30 to 15:00
4. Accepted update

At this point, in the Outlook web UI I can see a single meeting from 14:30 to 15:00, while in the Evolution calendar view I can see two meetings - one between 14:00 and 15:00, and one between 14:30 and 15:00 .
Comment 1 Milan Crha 2016-08-29 16:23:50 UTC
Thanks for a bug report. I think it is related to bug #770198, but to be sure, could you save both instances from the evolution as iCalendar (in the context menu above the event) and then check whether it has any line starting with EXDATE, like in my case:

   BEGIN:VEVENT
   ...
   EXDATE:20160831T130000Z
   ...
   END:VEVENT
Comment 2 Robert Munteanu 2016-08-31 07:55:50 UTC
Neither of the files has that line

$ file *.ics
event1.ics: vCalendar calendar file
event2.ics: vCalendar calendar file
$ grep -e EXDATE *.ics

Looking at the ICS files I noticed that one is an 'regular' recurring event, and the other is an update for a single occurence. 

$ grep -e ^RRULE *.ics
event1.ics:RRULE:FREQ=WEEKLY;UNTIL=20161216T120000Z;INTERVAL=2;BYDAY=FR;WKST=SU

Also, they have the same UID entry:

$ grep -e ^UID *.ics
event1.ics:UID:45E361AE-66A6-4D92-BBAD-BE58C178CC05
event2.ics:UID:45E361AE-66A6-4D92-BBAD-BE58C178CC05
Comment 3 Milan Crha 2016-08-31 08:25:22 UTC
They will have different RECURRENCE-ID. Would it be possible to save the whole series into a file, censor anything private in that file and upload it here for testing, please? You can locate the file in

    ~/.cache/evolution/calendar/<ews-calendar-uid>/calendar.ics

grepping for the UID and copy all lines between BEGIN:VEVENT and END:VEVENT (inclusive) which contain this UID. It's better than saving the event from the evolution, because it saves only the instance, instead of the whole series.
Comment 4 Robert Munteanu 2016-08-31 08:34:21 UTC
Created attachment 334508 [details]
Events matching UID from Evolution's calendar storage
Comment 5 Milan Crha 2016-09-01 08:58:49 UTC
Thanks for the event. The problem is that the RECURRENCE-ID doesn't match the time it is overwriting. That is, instead of pointing to midnight:
   RECURRENCE-ID;TZID=W. Europe Standard Time:20160826T000000
is should point to the 13:00 to be paired with the existing occurrence:
   RECURRENCE-ID;TZID=W. Europe Standard Time:20160826T130000
which it replaces.

The question is which software created that RECURRENCE-ID. If it was evolution, or any of its 3rd-party plugins, then it can be fixed on the evolution side (or on the side of that particular plugin), otherwise it's out of the evolution hands.
Comment 6 Robert Munteanu 2016-09-02 11:48:48 UTC
(In reply to Milan Crha from comment #5) 
> The question is which software created that RECURRENCE-ID. If it was
> evolution, or any of its 3rd-party plugins, then it can be fixed on the
> evolution side (or on the side of that particular plugin), otherwise it's
> out of the evolution hands.

How can I find that out?
Comment 7 Milan Crha 2016-09-02 12:14:47 UTC
When you try the steps from comment #0 on a test meeting from a Web interface, or a different client accessing the server using EWS, and then repeat the same steps for a different test meeting from the Evolution. If both will be broken, then it's likely that the problem is not in the evolution(-ews), otherwise it'll prove that the problem is on the evolution(-ews) side.

Maybe this is partly related to:
 https://bugzilla.redhat.com/show_bug.cgi?id=1369267
Comment 8 Martin 2017-04-07 10:35:49 UTC
I am seeing the same behavior as described at https://mail.gnome.org/archives/evolution-list/2017-April/msg00025.html. In my case, it looks to be related to the RECURRENCE-ID as described above:

RECURRENCE-ID;TZID=Romance Standard Time:20170404T000000

RECURRENCE-ID;TZID=Europe/Paris:20170404T100000

I assume events are created- and manipulated by MS outlook
Comment 9 André Klapper 2021-05-19 11:01:03 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/

Thank you for your understanding and your help.