---- Reported by patrick.ohly@intel.com 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 patrick.ohly@intel.com 2011-06-17 10:13:02 +0000 ----

See commit 78955078fac5344ef2230873957cb74e3c9e24cd



---- Additional Comments From patrick.ohly@intel.com 2011-07-19 15:54:57 +0000 ----

See also commit d39ba4. It does the same thing for eds_event testItems.



---- Additional Comments From patrick.ohly@intel.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:

commit cb25e44871eee615f1b3fc75163bc0f783120dc9
Author: Patrick Ohly <patrick.ohly@intel.com>
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
    http://code.google.com/p/google-caldav-issues/issues/detail?id=38).
    
    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
    (alternative solution).
    
    The same error is not handled when creation fails. This might need
    further investigations.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 19484 at https://bugs.meego.com/show_bug.cgi?id=19484