Because of Google issue with detached recurrences without parent
(http://code.google.com/p/google-caldav-issues/issues/detail?id=58)
and the SyncEvolution workaround (replacing RECURRENCE-ID with
X-SYNCEVOLUTION-RECURRENCE-ID) only one detached recurrence per UID
can be stored.
Removing the second modified recurrence from the test cases for
Google.
The parent with single detached recurrence was too simplistic. More
than one detached recurrence is necessary to trigger a problem in the
EDS calendar backend.
Because the "parent + single detached recurrence" may also be a relevant
special case, it is also still covered.
Finally, importing multiple detached recurrences without parent also
needs to be covered.
Missing is importing of a single detached recurrence. This should
be covered by importing the first of the two detached recurrences.
VALARM must have a DESCRIPTION. Found when testing against the latest
Apple Calendar server, which checks that. Fixed by adding the default
Google "event reminder" description.
Google Calendar replaces explicit DESCRIPTIONs in a VALARM with
a generic "This is an event reminder" and adds it when there
is no DESCRIPTION.
Let's ignore that while testing by setting that Google default text in
the Google testItem test data.
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.
This needs further investigation, see BMC #19484. In the meantime I am
removing the problematic test case to get the testItems test to pass.
Same as commit 789550 for testImport.
Google Calendar modifies the RRULE of a recurring event. The
transformation is semantically correct, but breaks the strict
comparison in the Client::Sync::eds_event::testItems test.
Fixed by making the same change in the reference test data for Google
Calendar.
Google Calendar recognizes the "custom US time zone" despite using
different names for TZID and TZNAME. Probably uses the offsets. When
it recognizes the zone, it replaces it with its own internal zone,
which breaks the test.
That's okay, so let's stop using this particular test event to get the
test to pass.
Google Calendar converts UTC time stamps into the time zone of the
calendar as set when the event is stored in the calendar. This changes
the semantic of the event slight, in particular for recurring events,
but is acceptable and is done correctly for the event's point in time
by Google, so let's accept this change.
This commit adds the Europe/Berlin time zone to the test data used for
CLIENT_TEST_SERVER=googlecalendar Client::Sync::eds_event
so that the change above no longer occurs in the testing and thus doesn't
break the test.
Because a time zone is set explicitly and preserved by Google, the Google
Calendar time zone setting doesn't matter for testing.
