As confirmed by Cyrus Daboo, Apple Calendar Server 5.2 should
return VTIMEZONE embedded in the item data if matching against
well-known timezones fails. This broken when Apple implemented
support for timezones via reference.
Long term we need to support that feature, but for now it and
this bug are not important because for most timezones, we should
be fine with our TZID based mapping. Ignore the issue during
testing...
The WebDAV backends contained a hack where the UID inside the data was forced
to be identical to the resource name. This is wrong for items created by us
via POST (because the server may choose a resource name != UID) or by some
other entity (where we have no idea how the resource name got chosen).
This commit removes the hack. Testing must be updated to pass correct data
with the same UID as on the server when updating an item, because the backend
will no longer ensure that and changing the UID of a resource gets rejected by
some servers.
The hack was introduced for peers which do not store the UID (for example, a
vCard or iCalendar 1.0 based SyncML client). A better solution must be found,
probably involving the Synthesis engine and its read/update/write cycle.
Specifying the language of the email address did not make much sense
to start with, even if EDS does (did?) it that way originally. Akonadi
strips LANGUAGE=en. Instead of filtering that out for Akonadi, better
simplify the test data.
Google CalDAV server does not handle \\\n properly. It adds
an extra backslash. Avoid this aspect of the test case because
a fix on the server side has been slow in coming.
eds_event.ics.googlecalendar.tem.patch is used with
Client::Sync::eds_event and Google CalDAV as server. google_event.ics
is used for Client::Source::google_caldav.
Google CardDAV parser/encoder swallows white spaces, possibly because
of the differences between vCard 2.1 and 3.0. It also escapes the colon
although it shouldn't.
Google is looking into this, so I am not trying to work out a workaround and
merely remove the problematic fields (mostly NOTEs and one URL) to get the
tests to pass.
An explicit CHARSET parameter causes the Google CardDAV server to drop
the NOTE, even if the charset is UTF-8. Removing this know problem from
the test set because it shouldn't happen in practice.
Since the "EDS contacts: avoid unnecessary DB writes during slow sync due to
FILE-AS" change, eds_contact::testItems failed because the "bday;special UTC
offset" (specific to Exchange testing) test user had no FILE-AS set, while the
one eventually stored in EDS had (because of the slow sync patch). Using EDS
3.8 probably would have triggered the same issue.
Fixing this by adding the FILE-AS property to the reference data. This is
a hard requirement now for tests to pass with EDS.
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.
Somehow the second modified recurrence made its way back into the
test data while rewriting the generic eds_event.ics.
Was lost earlier during syncing. Must be defined in field list and
vCard profile. Still not supported by PIM Manager, because folks doesn't
support it (see FDO #60373).
Testing shows that compared to Exchange, some additional problems
exist, which are ignored via synccompare:
- FN gets overwritten.
- CATGEORIES are lost.
Not sure whether anything can be done, so let's consider this
permanently broken.
BDAY also gets modified. Perhaps that can be fixed, so a synccompare
workaround will be commit separately so that it can be reverted later.
Funambol cannot represent "completed: 99%". It turns that
into 100% completed. Therefore the Funambol test data
uses "in-process: 78%". However, that was misspelled as
"in-progress", which caused testConversion to fail.
Not sure anymore why it was spelled like that (perhaps
Funambol used it that way?) and why this did not cause
problems earlier.
Memotoo does not store time zone information in its database. When
talking to a client, it can send either UTC or local time. As
discussed on the mailing list ("[SyncEvolution] Memotoo: conversion to
floating time"), Memotoo now sends all time stamps as floating time
in the time zone configured on the server, without specifying that
time zone in the data. The client must be configured to use the same
time zone.
Floating time is preferred over UTC because then Evolution will
use the local time zone definition when computing recurrences. It
would not do that if UTC was specified.
For some internal reasons, previously Memotoo sometimes still
used UTC. Now that is fixed, which required updating some of
the test data.
Only the first VEVENT of each item seem to be stored.
Avoid testing anything related to RECURRENCE-ID in
the import tests and skip the linked items tests.
Memotoo supports PERCENT-COMPLETE now. However, it sets the value to
100% if the status is completed. Therefore we can't have the 99%
complete value in the eds_task test, as for other servers.
Exchange 2010 insists on converting non-recurring events
into its own time zone. Various workarounds were tried
in activesyncd, without success.
To get the testing to pass, the testcases were adapted
to match the data returned by 123together.com. The obvious
downside is that anyone else running the tests against
a different Exchange server will need to adapt the data.
The second modified recurrence had an unintentional overlap in the
resulting start/end time. While this is acceptable according to the
iCalendar 2.0 standard, it is unusual and rejected by the Exchange
server when using ActiveSync.
Changed the test data to have each recurrence on the orginal day.
For example, only one Jabber account could be synchronized. This
was caused by an incomplete definition of the conversion to and from
vCard.
The test for multiple X- chat extensions is currently only done
in combination with Synthesis because that server is known
to support multiple instances of them.
This combination is missing in the base eds_event.ics because time
zone handling is problematic with some peers. With Apple Calendar
server this works okay.
Found out that Memotoo supports the country field, albeit only if the
string is recognized by Memotoo. That wasn't the case for some of the
test data.
Adapted the test data to use countries that Memotoo knows (Germany,
France, with the English names). Also updated synccompare.pl to
reflect the current set of lost properties and removed the Memotoo ADR
simplification.
(cherry picked from commit 4dd89c8626)
Found out that Memotoo supports the country field, albeit only if the
string is recognized by Memotoo. That wasn't the case for some of the
test data.
Adapted the test data to use countries that Memotoo knows (Germany,
France, with the English names). Also updated synccompare.pl to
reflect the current set of lost properties and removed the Memotoo ADR
simplification.
The Synthesis installation on plan44.ch stores X- extensions,
but currently replaces \; in the incoming vCard 3.0 with ;; in
the outgoing vCard 2.1. Avoid this aspect of the test for the time
being.
Memotoo now sends EXDATE with date/time values if the event iself has
a time in its DTSTART. That's more consistent with the iCalendar 2.0
semantic, but requires changes in the test data.
The recently added "Recurring 3" events do not work with ActiveSync at
the moment because detached recurrences cannot be stored via
ActiveSync (BMC #22831). Temporarily avoid them when talking to
Exchange.
Started CalDAV/CardDAV testing against Oracle Communications Calendar
server (formerly known as Sun Java System Calendar Server).
The only necessary workaround is to ignore
X-S1CS-RECURRENCE-COUNT (added to VEVENTs) and to avoid the \\\n
sequence which is incorrectly expanded to \\\\n by the ical4j
component (also affects Bedework).
Another known difference found by testing is that Oracle sends
semicolons unescaped in vCard 3.0. Will be fixed in the server.
The only other EXDATE test uses a time and thus VALUE=DATE-TIME for
EXDATE. The new test cases uses VALUE=DATE for DTSTART and thus
EXDATE.
Probably will need adapting for various servers.
Although IMHO it is not explicitly specified by iCalendar 2.0, it is
good practice and in fact expected by at least two servers (Apple
Calendar Server, Oracle Communication Calendar Server) that DTSTART
and EXDATE are using the same time format. If DTSTART is UTC, so
should be EXDATE, same for TZID and DATE-TIME/DATE.
Conflicts:
configure.ac
test/ClientTest.cpp
test/testcases/eds_event.ics.funambol.tem.patch
Conflicts because of version number and updated test cases resp. local
delete optimization.
ActiveSync backend had to be adapted to modified InsertItemResult: now
it requests a merge when it detects duplicates, like the CalDAV backend
already did on the 1.2 branch.
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.
Apple (correctly?!) sends back the X-TEST PARAMETER2 without quotation
marks around the value, despite it containing spaces. This confuses
the EDS vCard parser. To get the test to pass let's avoid this
particular aspect when talking to Apple Calendar Server.
Memotoo does detect RECURRENCE-ID/UID when importing events during a
sync, it just doesn't store it. It uses that information to add an
EXDATE to the recurring event.
Adapted the test data so that it has RECURRENCE-ID (lost, but that is
ignored by synccompare) and EXDATE (checked by synccompare). A real
test would be to not have EXDATE and check that they get added, but
this kind of semantic transformation currently cannot be tested
automatically.
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.
The recently introduced VALARM:DESCRIPTION is dropped by
Funambol, despite it being mandatory in the iCalendar 2.0 standard.
Let's ignore this, by not using DESCRIPTION in the Funambol
test cases.
(cherry picked from commit e23c63396b)
FN, name prefix, PO box, LABEL, anniversary and spouse not supported
by ActiveSync. BDAY also supports UTC time (+-hh:mm also supported by
the vCard -> EAS conversion, but cannot be tested because it gets
converted to absolute UTC).
EMAIL and TEL have very specific requirements. The "John Doe" contact
covers all supported type combinations.
No chat handles supported. ActiveSync has exactly one, without
specifying what it is for.
TZIDs and TZNAME are not preserved (and don't have to).
Events without RRULE are converted to UTC by Exchange,
use simple RRLULE to prevent that. RRULES are sometimes
rewritten a bit.
EXDATEs are always date-time. The date-only case is probably not
supported correctly by activesyncd (need to test).
Meeting invitations end up with organizer == calendar owner.
Need to check how this works with meeting invitations. Ignore test
case for now.
Custom time zones work in principle, but the one in the base test
got mangled. Need more real-world tests.
The recently introduced VALARM:DESCRIPTION is dropped by
Funambol, despite it being mandatory in the iCalendar 2.0 standard.
Let's ignore this, by not using DESCRIPTION in the Funambol
test cases.
Bug https://trac.calendarserver.org/ticket/436 was resolved,
the latest Apple Calendar server supports line breaks in ADR.
Therefore we can stop using special test cases for Apple.
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.
