On Thu, 2010-04-15 at 11:06 +0200, Patrick Ohly wrote:
On Wed, 2010-04-14 at 20:29 +0100, Ahmed Guellil wrote:
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.
My theory is that this fails because Memotoo does not support the UID
property (known limitation) *and* the software which created the
recurring event did not include an exception.
Let's test... hmm, I don't find a way to modify one particular
occurrence on the Memotoo web interface, so I cannot test the
Ahmed, I need you help there. Can you save both the main event and the
detached recurrence in Evolution and attach it to your reply? Please
remove sensitive information.
This is still relevant. What I don't understand is how Memotoo avoids
displaying the recurring event on the day of the detached recurrence. If
it is via EXDATE, then it should also work in Evolution.
Unless Memotoo never sends the exception... perhaps you can modify the
recurring event, sync with Evolution using a higher log level
("syncevolution --run --sync-property loglevel=4 memotoo"), then check
the log ("syncevolution --print-sessions memotoo") and quote the
incoming VEVENT as it is sent by Memotoo?
> - a detached recurrence on Evolution is duplicated on Memotoo
> 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).
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.