For testing sources instantiated via SyncSource.cpp (for example, EDS)
and client-test-app.cpp (ActiveSync) append the name of the server set
via the CLIENT_TEST_SERVER env variable to target-config@client-test,
separated by a hyphen.
This allows configuring testing differently for different servers.
Was already done for CalDAV sources, inside WebDAVSourceRegister.cpp.
The gdbus utility library crashed here if interface->properties was NULL:
for (property = interface->properties; property->name; property++)
^^^^^^^^^^^^^^
Fixed by checking property for non-NULL in the for loop.
More global initialization/destruction ordering problems appeared
on current Debian Testing (gcc 4.6.1, binutils 2.21.52.20110606-2):
- WebDAVCredentialsOkay registered and visibility modified before
constructed, which later resets visibility
- test setup uses config before config properties are registered
- logger stack deallocated before later destructor attempt to use it
Fixed with:
- WebDAVCredentialsOkay() singleton
- delay all work in test setup until really needed
- never deallocate logger stack, use singleton
The code which removed TZIDs after a e_cal_get_component_as_string()
had a memory handling problem: icalproperty_get_next_parameter()
after removing the parameter accesses freed memory.
Found when running with a broken libical (compiled from source) that
couldn't resolve its own internal TZIDs.
Instead of fixing the "remove all TZIDs" approach, let's use the
simpler "remove first (and probably only) TZID". Also added some
debugging code.
This finishes the partial commit for this problem which was accidentally
committed earlier as part of af43ac9.
An invalid syncFormat (like text/vcard for "Evolution Calendar")
can prevent instantiating the source. Therefore include that
value in the error message and clearly distinguish between
sync and database format.
Sony Ericsson seems to use ISO-8859-1 for all their phones. This
causes two problems:
- mangled characters and/or
- crashes inside libecal/gdbus
It is uncertain whether all devices have this problem. A poll did not
yield any results
(http://syncevolution.org/blogs/pohly/2011/question-sony-ericsson-users-charset). So
let's change it for those who have reported problems.
To revert the change, copy
/usr/share/syncevolution/xml/remoterules/server/00_sony_ericsson.xml
into $HOME/.config/syncevolution-xml/remoterules/server (after
creating that directory) and remove the lines with ISO-8859-1.
This was originally reported for contacts, and now also for calendar
data. The calendar case was seen as a crash of the syncevo-dbus-server:
GLib-CRITICAL **: g_variant_new_string: assertion `g_utf8_validate (string, -1, NULL)' failed
Program received signal SIGSEGV, Segmentation fault.
g_variant_is_trusted (value=0x0)
at /build/buildd/glib2.0-2.28.6/./glib/gvariant-core.c:600
in /build/buildd/glib2.0-2.28.6/./glib/gvariant-core.c
Thread 1 (Thread 0xb7fce850 (LWP 3402)):
at /build/buildd/glib2.0-2.28.6/./glib/gvariant-core.c:600
at /build/buildd/glib2.0-2.28.6/./glib/gvariant.c:3081
at /build/buildd/glib2.0-2.28.6/./glib/gvariant.c:4093
app=0xbfffca4c) at /build/buildd/glib2.0-2.28.6/./glib/gvariant.c:4248
at /build/buildd/glib2.0-2.28.6/./glib/gvariant.c:4188
in_calobj=0x8435fe8 "BEGIN:VEVENT\r\nSUMMARY:THW Sim Pr\374fung\r\nDTSTART:20070420T230000Z\r\nDTEND:20070421T225900Z\r\nBEGIN:VALARM\r\nTRIGGER;VALUE=DURATION:PT45M\r\nACTION:DISPLAY\r\nEND:VALARM\r\nEND:VEVENT\r\n",
Evolution shows a meeting twice on the day of a modified recurrence,
if the meeting series was originally created and modified in Exchange,
then imported into Google Calendar.
The reason is that the RECURRENCE-ID in that case ends up being
in UTC, even if the parent event has a time zone. Evolution and/or
libical seem to have a bug here, IMHO they should recognize that the
RECURRENCE-ID time is the same.
SyncEvolution now works around this by transforming the UTC
RECURRENCE-ID time into the time zone of the DTSTART time of the
parent event. This is combined with removal of X-LIC-ERRORS into
a new fixIncomingCalendar() method which needs to be called
whenever a complete VCALENDAR is received from the CalDAV server
(adding data from a report, GET).
This transformation changes the "rid" part of the item IDs. It should
be okay in a two-way sync (remove one sub item, add another) and
a slow sync (libsynthesis recognizes the times as equal).
Added some more functions needed to work with DTSTART and RECURRENCE-ID.
Removed icalproperty_vanew_lastmodified() because its entry was incomplete
and unused.
Nightly testing did not resend a PUT when it could (should?)
have because the deadline was exceeded. Added logging to
track down what the chosen deadline is.
Instead of aborting the test at the first item which
fails to import, collect the error messages (from the
exceptions), do the comparison of imported data
against the reference data and then either report
the import failures (if there were any) or the comparison
failure (if that broke).
The advantage is that a single run of the test shows
all problems that exist.
Use checkPassword() before trying to --print-items. This will either
prompt for the password at command line, or ask it from the keyring
if --keyring is specified (or if using the dbus server).
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.
During an incremental sync, when an unmodified meeting series on the CalDAV
server had to be extended (= adding a detached recurrence), the operation failed
with "event not found".
The root cause was a bug in updateAllSubItems(): due to a copy-and-paste bug,
it cleared the cache instead of adding the modified items to it. Therefore
unmodified items, added to the cache earlier, where not found later on.
Normally they weren't needed. The exception is reading in preparation
for adding a detached recurrences.
Fixed by removing the m_cache.clear(). That is valid in this case even
if the operation is repeated, because adding already read items will
simply overwrite them.
Also added some debug logging which helped to track this down.
If the same event was deleted both locally and in the CalDAV server, syncing
failed with "event not found".
It is normal that the Synthesis engine requests the removal of
non-existent items. CalDAVSource needs to handle that in
removeSubItem() and getSubDescription().
Item operations like --print-items failed if the configuration didn't exist:
[ERROR] : virtual read-only configuration node, cannot write property webDAVCredentialsOkay = 1
This was caused by trying to write the webDAVCredentialsOkay property
into a temporary, read-only configuration. The fix is to check for
read-only configs before attempting to use the property.
Alternatively it would have been possible to catch exceptions, but it
is not obvious which errors can be ignored.
Some users of ConfigNode (like the WebDAV backend) need to know
whether setting a optional property will succeed before attempting
it. When they know that it fails because the node is read-only, they
can skip setting it.
The alternative would be to throw a well-defined exception and catch
it, but that is not in line with the SyncEvolution design. Exceptions
should be for real, unexpected errors.
Notifications were meant to be shown for all errors except temporary
ones (http://bugzilla.moblin.org/web/bug_report_10000.html). This has
never been implemented correctly since the feature was introduced:
instead of hiding known temporary errors, all errors except 500 (fatal
error) were suppressed.
This commit switches to white listing the known errors which are
temporary and suppresses those. Right now that happens to be only one,
network problems.
Use the new READ() script method in libsynthesis to inline local photo
data right before sending to a remote peer.
Tests were added in combination with SyncEvolution server for inlining
a special well-known file (testcases/local.png) and failing to inline
(file doesn't exist). In the latter case the URI is sent unchanged.
The VALUE parameter was ignored completely and thus got lost in the
Synthesis engine. Added it as a string.
The TYPE parameter was an incomplete enum. Better allow arbitrary
strings.
Both parameters must be copied together with the PHOTO data they
belong to. In combination with merge="fillempty" this can be
problematic: if one of the parameters is empty, it may be overwritten
although the PHOTO data is not copied.
This problem is solved by ensuring that the internal field list never
has empty PHOTO_TYPE/VALUE fields. This is done by setting "binary"
resp. "unknown" when importing contact data from a peer or the local
Evolution backend and removing them again before sending to a peer or
storing.
The same change needs to be done with other backends. It is not made
mandatory because some backends (like file) might want to store these
values explicitly.
Because it is unknown which peers support VALUE=uri, only the
CLIENT_TEST_SERVER=syncevolution testItem testcases contain a contact
with such a PHOTO.
When neither Network Manager nor ConnMan are running, network presence was "not
online". This prevented running automatic syncs. Primarily (exclusively?) affected
nightly testing in the minimal chroots.
The solution is to detect when both managers were not found on D-Bus and
then set the status to "online".
Evolution and the MeeGo UX assume that first/middle/last name are set.
That is not the case when a contact is created in the Google Contacts
web interface. Such contacts are sent by Google without the N
property. That is surprising because Google supports the N property
(it is returned for contacts created via SyncML, and internally Google
distinguishes between the name components).
This commit adds a workaround for all peers (not just Google) which
ensures that first/middle/last name are set whenever possible. If FN
is set, it is split so that the first and last word are first/last
name, the rest is the middle name. As a special case a trailing comma
at the end of the first words is recognized as "Doe, John Middle"
format.
If the full name is empty, the first email address and (if that is also
empty) the first phone number are used as additional fallbacks for the
first name.
syncevolution.org binaries are compatible with Evolution 2.32 thanks
to loading libecal/libebook dynamically. Release 1.1.99.5 warned about
the libs from Evolution 2.32 as "might not be compatible!" which is
unnecessary. They are compatible.
Bumping the version numbers to avoid the warning.
Most of the selected theme icons don't exist, so adding these values
only provides the possibility to add icons later on.
For Google Contacts, the existing gmail icon is used as a short-term
solution until the theme gets a proper google-contacts icon.
Due to too restrictive checking of the syncURL, configs without http
or obex-bt were never executed automatically. This commit adds a
fallback which enables "other" configs to run without checking for
peer presence.
In addition it marks all "local" syncs as needing HTTP
connectivity. This is a simplification that fits the current use
cases, but needs to be enhanced later on.
Auto-sync sessions did not properly activate their D-Bus support and
thus couldn't be accessed via the Session D-Bus API. Must have
affected showing progress of such sessions in the GTK sync-ui.
They also weren't kept around for one minute, like the sessions
started by a client. Therefore UIs which need to retrieve information
about a completed session failed for a second reason.
Fixed by adding the necessary "activate()" and use "addTimeout()"
trick for session expiry also in the AutoSyncManager. The later was
moved into DBusServer for that.
These issues were found with the new
TestSessionAPIsDummy.testAutoSyncFailure D-Bus test.
When a config was set to "auto-sync on", the AutoSyncManager added it
to a list, but did not prevent the server from shutting down. Not sure
how this was meant to work or when it broke.
Fixing it is easy: as long as AutoSyncManager has at least one config
lined up for auto-syncing, it holds a reference on the AutoTerm
instance and thus prevents shutting down.
This commit also adds test cases for various situations:
- prevent shutdown while auto-sync on
- re-enable shutdown while timer is running
- re-enable shutdown while timer is off
g++ 4.6 and ld 2.21.52.20110707 (Debian Unstable) led to a different
order of global instance construction:
1. WebDAV constructor calls SyncConfig::getRegistry()
2. getRegistry() adds the (uninitialized!) property instances
and modifies them
3. SyncConfig.cpp instances are initializes, which resets
some of the values modified by getRegistry()
The result was that, for example, the "defaultPeer" property was
treated like an unshared property and written into the wrong config
file.
The assumption that variables in a compilation unit are initialized
before methods in that unit can be called is not based on anything in
the C++ standard. Therefore this commit rewrites the code so that
properties are not added/updated inside the getRegistry()
methods. Instead this is done in separate classes which (and that is
guaranteed by the C++ standard) are constructed after the properties
defined earlier in the compilation unit.
g++ 4.6 complains about the unused assignment. Probably this boolean
result needs to be checked. But as GDBus will be replaced soon anyway,
don't bother now.
In contrast to the Yahoo template, this one doesn't mention
a specific service and enables both contact and calendar sync.
To be used with a service that supports auto-discovery.
The previous commit added a check for qmake, but then used QMAKE
without checking whether qmake was found at all. This caused configure
problems on systems where qmake wasn't available.
The error handling also wasn't correct. A "test" was missing in front
of the comparison.
Commit 3f1185, contained in 1.1.99.3, changed
SyncContext::throwError() so that it throws a StatusException with
STATUS_FATAL. Previously a runtime exception was thrown, which
Exception::handle() recorded as a local error.
This commit fixes that regression by throwing a STATUS_FATAL +
LOCAL_STATUS_CODE, which restores the traditional result of
throwError().
Found by test-dbus.py TestDBusSyncError.testSyncNoConfig.
Parsing the revision map extracted the wrong subset of the string. As
a result, the revision comparison was broken and reported more changes
than really existed. Showed up as a failure in
Client::Sync::eds_event::testOneWayFromClient and requests for items
in a multiget when it wasn't needed.
The "retry on 401" code wasn't active during the initial sync
because the fact that the credentials had been accepted before
was only recorded on disk, but not in memory.
Moving the response handling from the data element to the response
element caused problems with Google, because it sends a 404 status for
the collection with no data. Apple Calendar Server didn't do that when
testing the change manually, so the problem only showed up in the
nightly testing.
This patch restores the previous behavior of simply ignoring responses
with no data. Some better error handling might be useful.
As discussed on the mailing list, "source-config" is ambiguous because
the "addressbook/calendar/..." configs are also called "source
configs".
Now the naming is "sync" config (for the config with syncURL=local://,
because it is used for syncing) and "target" config (because it is
used as target in a sync config's syncURL).
Rejected:
"local" config - because the databases are not necessarily local
"source" config - see above
"client" or "server" config - because both sides might use local data
and/or client/server could refer to the role
of the peer or the SyncML client/server model
used internally
The Funambol template hadn't been updated and the command line
tests failed because the didn't expect the PeerName to be set.
The normalization of "= F" to "= 0" broke the "= Funambol" peer name.
Doesn't seem to server any useful purpose anymore, so removed.
