---- Reported by email@example.com 2010-04-22 01:19:10 +0000 ----
Problem: recurring events are shown twice by web services when modifying specific instances of it.
Problem was originally discussed in the "[SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo (was: Re: A synchronization server named Memotoo)" mail thread.
Root cause: many servers ignore UID and RECURRENCE-ID and thus display recurring events and detached recurrences incorrectly after sent by SyncEvolution.
In iCalendar 2.0, detached recurrences are linked to the recurring event
via their UID. If there is a VEVENT with UID=<foo> and
RECURRENCE-ID=<date>, then the main event is not to be displayed on
<date>, only the detached recurrence is.
In addition, some software also adds an EXDATE exception in the main
event for <date>. I don't think this is required.
> > - a detached recurrence on Evolution is duplicated on Memotoo but not
> > on Evolution, even after resync.
> This I can reproduce, and it fits my theory. When modifying one
> recurrence, Evolution 2.38.3 did not update the recurring event, so all
> that Memotoo is sent is one VEVENT with UID and RECURRENCE-ID. It then
> ignores the UID and thus displays the main event and the detached
> Thomas, does that make sense? Any suggestions how this could be fixed?
We've had the same problem with Funambol. At that time I didn't have an
idea, but after writing down the explanation above and thinking some
more about it, here's something that might work: when a new VEVENT gets
added in Evolution with RECURRENCE-ID for an existing, unmodified
recurring event, then modify the recurring event by adding an exception.
Then sync both the main event and the child to the server.
Evolution doesn't do this because iCalendar 2.0 doesn't require it, but
as workaround for servers with incomplete iCalendar 2.0 semantic (like
Memotoo and Funambol) it is necessary and should have no negative side
effects (well, except for more complicated client code and slightly
increased network traffic).
---- Additional Comments From firstname.lastname@example.org 2010-06-01 19:33:33 +0000 ----
The depending https://bugs.meego.com/show_bug.cgi?id=1916 has been fixed well.
---- Additional Comments From email@example.com 2011-10-26 14:46:49 +0000 ----
(In reply to comment #0)
> We've had the same problem with Funambol. At that time I didn't have an
> idea, but after writing down the explanation above and thinking some
> more about it, here's something that might work: when a new VEVENT gets
> added in Evolution with RECURRENCE-ID for an existing, unmodified
> recurring event, then modify the recurring event by adding an exception.
> Then sync both the main event and the child to the server.
The CalDAV backend does this for the Maemo Calendar backend, see "[SyncEvolution] Recurrences in Maemo 5".
The problem is that this transformation really belongs into the engine. I don't want to add such hacks also to the EDS calendar backend. The only sane way to solve this issue is improving the Synthesis engine so that it works with a set of items internally, see https://bugs.meego.com/show_bug.cgi?id=23761.
--- Bug imported by firstname.lastname@example.org 2012-07-29 20:36 UTC ---
This bug was previously known as _bug_ 1180 at https://bugs.meego.com/show_bug.cgi?id=1180
This bug depended on bug(s) 23761 1916.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/56.