---- Reported by firstname.lastname@example.org 2011-06-17 10:10:30 +0000 ----
The Google server seems to think that it can take over meeting acceptance/decline handling when new events are stored on the server.
For example, PARTSTAT=ACCEPTED gets replaced with PARTSTAT=NEEDS-ACTION.
It has also been observed that participants and organizer get overwritten.
There might be nothing that we can do about it. Investigating a bit more would be worthwhile, though.
In the meantime I'm simplifying the test/testcases/google_event.ics by removing the "meeting invitiation" test case.
---- Additional Comments From email@example.com 2011-06-17 10:13:02 +0000 ----
See commit 78955078fac5344ef2230873957cb74e3c9e24cd
---- Additional Comments From firstname.lastname@example.org 2011-07-19 15:54:57 +0000 ----
See also commit d39ba4. It does the same thing for eds_event testItems.
---- Additional Comments From email@example.com 2011-08-03 12:15:35 +0000 ----
Meeting invitations also turned out to be problematic in practice because of Google CalDAV bug http://code.google.com/p/google-caldav-issues/issues/detail?id=38
I ran into the "403 You don't have access to change that event." problem, both for updating a series (adding a detached recurrence) and when creating it.
I haven't been able to pin it down exactly. Might have been caused by invalid UID property values in my calendar. Here's a slight improvement when this problem hits:
Author: Patrick Ohly <firstname.lastname@example.org>
Date: Wed Aug 3 12:59:43 2011 +0200
CalDAV: continue despite Google Calendar access problems (see BMC #19484)
Google Calendar checks whether a CalDAV client is allowed to update
particular events. In combination with meeting invitations this has
led to know issues where desirable changes were rejected (see
Details are murky whether that bug is still open. I hit the "403 You
don't have access to change that event." problem both in updating
a meeting series and creating it.
This commit ensures that when updating fails, the errors is treated as
a temporary, per item error (417). The sync session then continues.
The overall result will be STATUS_PARTIAL_FAILURE = 22001 and the
next session will retry the same item. This is better than aborting
the session (situation without this patch) or ignoring the problem
The same error is not handled when creation fails. This might need
--- Bug imported by email@example.com 2012-07-29 20:36 UTC ---
This bug was previously known as _bug_ 19484 at https://bugs.meego.com/show_bug.cgi?id=19484
-- 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/10.