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.
"oracle" is used as server name for Oracle. Oracle Beehive also
still exists, but seems less relevant now.
"egroupware-dav" is used for eGroupware when using CalDAV/CardDAV,
to distinguish this from the older eGroupware SyncML testing.
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.
The Olson-style prefix is causing problems for some CalDAV
servers (Bedework, eGroupware) which only know about some kind of
prefices or do not support them at all.
This patch removes them for the Client::Source::*::LinkedItems_0
default test data.
Syncing automatically removes them as part of the time zone matching
done inside the Synthesis engine: all libical time zones are imported
with the simplified TZID, then after matching the more complex TZID
used by e.g. Evolution, the simplified TZID is used in the encoded
item.
When testing against a server which has an at sign in the principal,
the principal was checked over and over again, because the "already
seen" comparison failed for foo@bar != foo%40bar.
Fixed by pushing normalization into the "tried" instance and doing the
normalization in all cases.
Added additional logging of collection search. The fallback if the
display name is not found is changed to an empty string, instead of
using a non-translated string.
The initial limit of checking 10 candidates was too restrictive. Now
increased to 1000. It's unsure whether it is small enough to be
useful, but at least it shouldn't trigger unexpectedly anymore.
When a collection was identified as one we searched for, then don't
look at its properties. If the search started with the principal, then
we are not going to learn more from the collection's properties. If
the search starts with a specific collection, then the search will stop
after reporting that collection.
Not listing further collections when searching for all databases is
probably what the user wants. Otherwise he should have used the
principal or simple the host name.
These properties may contain more than one href. eGroupware does for
address books when the user configures to expose more than one address
book in the web interface for GroupDAV.
Now SyncEvolution adds all of these URLs as candidates. Ordering is
preserved, so the first URL in the property is also visited first (=
becomes the default).
eGroupware gives just a path as Location for a redirect. Accept that
by copying the missing pieces of information (scheme, host, port) from
the current session.
Typically all locations which add to the candidates list check first
whether the candidate was already visited before. This is useful
because it avoids growing that list unnecessarily and makes logging
slightly more informative (shows skipped candidates at the time when
they are found).
But if a candidate was accidentally added twice, it would be used
twice. So let's check again when picking a candidate from the list,
just to be sure.
When given just the host name and thus starting with the / path, also
look at .well-known URLs inside that host. Previously the code relied
on a redirect at that path, which happened to work for eGroupware but
isn't standardized.
Typically calendar/addressbook-home-set points to a collection which
contains calendar and addressbook collections. When scanning for one
kind of collection it is possible to ignore all collections of the
other kind, because those are guaranteed to not contain anything not
related to them.
This patch does that by accepting the right kind of collection and
those which cannot be ruled out for sure, which currently are CalDAV
and CardDAV collections.
The patch also scans sub-collections in alphabetical order, which
makes the result more deterministic.
Based on the previous code, which stopped when finding the first
collection. Now that code is an utility function which reports all
resources to a callback until told to stop by that callback.
Listing databases is now a dedicated operation, instead of being done
whenever syncevolution was invoked without parameters.
Advantages:
- can be combined with property assignments for backends
which do not work without that additional information
- can be done for configured sources
During testing, removing all items is done via a special call in
TestingSyncSource. It used to be an utility method which fell back to
the normal SyncSource API.
This patch changes several things
- Reversed order in which items are deleted in that utility method,
because removing children (= longer IDs) first tends to be supported
better by servers (bug in CalDAV server, but still...).
- Allow backends to implement their own removeAllItems().
- Implement that in CalDAV + MapSyncSource as removing the merged
items directly, instead of using a sequence of PUT+final DELETE.
Found while testing with Bedework CalDAV server. Makes testing more
robust and efficient.
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.
Somehow a PUT which removes the detached recurrence from a meeting has
no effect. Looks like a Google server bug. Keep testing, but ignore
the failure.
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.
TestingSyncSourcePtr manages anchors for all sources
created via it. These anchors used to be reused when
running multiple tests, which may have led to different
results compared to running tests by themselves. So now
the anchors get reset at the start of each test, detected
by the changed getCurrentTest() name.
This change was triggered by the observation that combining
Client::Sync::eds_event::testItems with Client::Source::google_caldav
failed in Client::Source::google_caldav::testChanges around
change tracking. The reason was that the anchor for an EDS source in
eds_event::testItems was reused as the anchor for a CalDAV source
in google_caldav::testChanges, which prevented a slow item scan
when it would have been needed.
The warning about reversed data direction in local sync also applies
to syncing with a phone. Therefore the warning is now listed more
prominently below the "--sync" command line option and was extended to
also cover direct syncing.
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.
Affects SyncEvolution 1.2: when bailing out of
EvolutionCalendarSource::retrieveItem() when EDS returned the wrong
component, that component wasn't freed (recent change). Fixed by
making it owned by a smart pointer as soon as possible.
eGroupware does not include ETags in quotes. SyncEvolution
unconditionally stripped the first and last character, making ETags
shorter than they really were. Now it strips them only if both are
quotation marks.
Replaced testLocalDeleteAll() with direct delete, because
testLocalDeleteAll() first does an insert which is just causing extra
traffic in tests which are meant to test something else.
When avoiding conflicting properties with merge=lines, items are
completely replaced as originally expected. This allows testing the
"server avoids unnecessary updates" aspect of add<->add conflict
resolution.
With an up-to-date libsynthesis (age comparison fixed, COMPARESCRIPT()
fixed, suppress unneeded local and remote updates, fix statistics in
server mode) these tests pass in server (local sync/CalDAV) and
client mode (with SyncEvolution as server).
Thus BMC #22783 is almost resolved, except for the open question
whether merge=lines is desirable in this case.
Several open issues break the original tests:
- merging conflicting data is server-dependendant and even with
SyncEvolution as server wasn't done as expected (merge=lines causes
DESCRIPTION and LOCATION to get concatenated)
- as a result, updates are sent when none should be necessary
- in server mode (= CalDAV), the Synthesis engine always counts the Add
commands as "added item" even if it ends up being an updated item
These needs further investigations. In the meantime make the tests pass
by using the same test item in all syncs and relaxing the statistics checking.
The previous commit 7411f7e had the password check in the code branch
for --print-items. --import/export/delete-items still had the same
problem. Moved the code.
Source passwords must also be checked, in case that "backendPassword"
is set. Added.
When configuring sources for an HTTP server, the config name typically
is just the context (@foo). When using the config in the HTTP server,
the config name is the peer inside that context (client@foo). Because
the GNOME keyring lookup keys for the "databasePassword" (more
specifically, the object name) contained the full config name which
was different in both cases, looking up the saved password failed.
The solution is to normalize the config name (to accomodate for
different ways of spelling it) and use only the context, with @ as
before. This will break existing setups where the object name in the
keyring (incorrectly) includes the full config name. In that case just
configure the source again to set the password anew.
e_cal_create_object() of a detached recurrence fails with "UID already
exists" if there is any other event with that UID, regardless whether
it is the parent or another detached recurrence.
When adding new items, SyncEvolution did not handle the case were
another detached recurrence, but not the parent, already existed. The
check for "UID used" must check for any item with that UID, not just
the parent.
When removing the parent, SyncEvolution temporarily removes detached
recurrences and recreates them later (can't be done differently with
older EDS). Recreating a second detached recurrence with
e_cal_create_object() then failed, must use e_cal_modify_object() for
it and all following recurrences.
Finally, EDS itself is confused when asked for a UID without
RECURRENCE-ID, as it happens during such a removal: instead of
returning the information that the parent doesn't exist (which
SyncEvolution handles), it returns the first child (which broke change
tracking by adding an entry for the non-existant parent). Worked
around by doing a sanity check on the returned data.
Because these additional changes would have been very slow with the
list of luid strings, m_allLUIDs is now a more complex map from UID to
set of RECURRENCE-IDs. This also makes some other code more
efficient (O(log n) instead of O(n), less parsing of luid strings).
EXDATE has a VALUE parameter, which wasn't defined in the XML
profile. Didn't seem to matter at all in practice, but wasn't
standard-compliant. Noticed while working on BMC #22940.
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.
