Hello!
Consider the following situation:
1. User A sets up a recurring meeting.
2. He invites user B for one (but not all) recurrences, which
happens to be modified (say, different summary).
3. User B receives the meeting invitation. It gets added to his
Exchange calendar.
4. User A invites him for the recurring meeting.
5. User B receives that meeting invitation.
The key question is: at step 3, is the meeting stored as a detached
recurrences, or whatever the corresponding Exchange semantic is?
If it is not, then how do Outlook/Exchange deal with the second meeting
invitation? If the existing event is not marked as a detached
recurrence, then the invitation looks like an update, which should
overwrite the old data instead of adding the parent event to it.
In SyncEvolution's client-test, this situation is covered by:
CLIENT_TEST_UNIQUE_UID=1 CLIENT_TEST_SERVER=exchange ./client-test
Client::Source::eas_event::LinkedItems_0::testLinkedItemsParentChild
Note that you need an up-to-date SyncEvolution and activesyncd source; I
changed the naming recently and fixed some aspects of the LinkedItems
testing.
What I now see is that SyncEvolution sends a VCALENDAR with one VEVENT
which has a RECURRENCE-ID. What comes back is that same event without
RECURRENCE-ID. I suspect that this will cause Evolution to fall into the
trap that I outlined above.
It depends a bit on what kind of meeting invitations are sent: is it one
for the parent, or one for parent and all detached recurrences? I don't
know, and the point is that different programs may deal with this
differently. I don't think the iCalendar 2.0 standard mandates a
particular behavior.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
