Re: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo
On Thu, 2010-05-06 at 23:34 +0100, Stefano Maffulli wrote:
On Wed, 2010-04-21 at 13:40 +0200, Thomas Pequet wrote:
> I can not arrive to reproduce the problem: the rule on Memotoo is
> successfully sent to Evolution and there is no duplicate.
I can help with testing this too, because I have noticed the same
behavior.
I created a new recurring event on Evolution. Synced to memotoo.
Modified one instance of the event on Evolution, adding a location and
modified the description. Synced to memotoo. Here is the output of the
sync session:
[...]
On memotoo server I see two events (see attached screenshot): one is
a
series of events, the other is an isolated one.
On memotoo site I modified the modified recurring event (the one that
shows up as duplicate in memotoo and synced. On Evolution I get 4
events, but the first one of the series is removed and two are
duplicated in the same day.
I'm not entirely sure why you get 4 events, but I think I can reproduce
the problem and have a fix. Tracked as
http://bugs.meego.com/show_bug.cgi?id=1916
What happens is that Memotoo sends us a VEVENT as update which has
neither UID nor RECURRENCE-ID. SyncEvolution already used to add back
the UID, but didn't do that for the RECURRENCE-ID. What thus happens is
that the updated VEVENT overwrites the original, recurring VEVENT,
instead of overwriting the single instance.
Normally I would expect the Synthesis engine to handle this, by
retrieving the existing item and updating individual fields. However,
this depends on knowing supported fields. Memotoo does not send CtCap
information and therefore this mechanism is skipped.
The same problem also occurs with the Funambol server, I just checked.
It also doesn't send CtCap. Stefano, why is that? Shouldn't it always
send that?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.