| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
A counterpart for E_CONTACT_X509_CERT.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We do not want the following two calls to behave differently:
e_vcard_attribute_new ("", "X-HELLO")
e_vcard_attribute_new (NULL, "X-HELLO")
Elsewhere in the vCard code, attribute group names are guaranteed to be
NULL or non-empty strings, so we should follow that precedent here.
https://bugzilla.gnome.org/show_bug.cgi?id=751044
|
| | |
|
| | |
|
| |
|
|
|
| |
The argument is not used in the code, it only makes easier debugging,
to recognize for which factory the subprocess is run.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is used to unset any failed cached credentials responses, thus
when the backend is closed, which means it is not interested in the
credentials anymore, the clients won't ask for them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
And re-check server availability during it too.
|
| | |
|
| |
|
|
|
| |
Typo in the code, which prevented the error to be propagated
back to the caller.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
As the 3.14 version will be skipped, to get back to sync with
the version of GNOME, then the right Since version is 3.16.
|
| | |
|
| |
|
|
|
| |
The password-based Google address book was opened read-only, because
of an incorrect check whether the password was accepted.
|
| |
|
|
|
|
|
| |
The EBackend::online state doesn't necessarily mean that the book is
also connected, thus the book_backend_webdav_get_contact_list_sync()
could fail with 'Authentication required' when it was tried to
download contacts in the state without credentials.
|
| |
|
|
|
|
| |
Since this change the client is responsible to provide credentials
to use to authenticate backends (through ESource-s, to be more precise),
unless the credentials are already saved.
|
| |
|
|
|
| |
As any other operations, thus there won't be any issue with the main
contexts (an assertion runtime message from GSimpleAsyncResult).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Commit 8231f94 broken ABI, by adding additional parameter to
e_phone_number_get_national_number function.
This patch is implementing fix for bug 735659 without breaking ABI, by
removing leading zeros from phone numbers in EBookSqlite directly.
|
| |
|
|
|
|
| |
The previous busy-wait could cause flood of the kernel with a lock
request, with basically no outer limit. This change adds a 15 seconds
time limit with a 100 ms delay between each lock request.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
E_BOOK_QUERY_BEGINS_WITH was checked against twice, which seems wrong.
Presumably, the second was meant to be E_BOOK_QUERY_ENDS_WITH, but I’m
not entirely sure.
Coverity issue: #1250456
https://bugzilla.gnome.org/show_bug.cgi?id=739495
|
| |
|
|
|
|
|
|
|
|
| |
fwrite() takes two integer parameters: size and nmemb. size should always
be constant, as it is a structure size. nmemb may vary. Using these two
parameters the correct way around means the return value is consistently
related to nmemb, and static analysers such as Coverity can perform
taint tests on the values passed to size.
https://bugzilla.gnome.org/show_bug.cgi?id=730381
|
| |
|
|
|
|
|
|
|
|
|
| |
This should never happen in practice, but it is good to be completely
explicit in the assertion.
Follow up to commit 10d55d18.
Coverity issue: #1250458
https://bugzilla.gnome.org/show_bug.cgi?id=730378
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a follow up to commit 2a5d6db6, since it did not eliminate the
use of tainted data in the sense that fread() was being called with a
variable-sized size argument, when it should be called with a
variable-sized nmemb argument.
Coverity issue: #1061517
https://bugzilla.gnome.org/show_bug.cgi?id=730381
|
| | |
|
| |
|
|
|
|
| |
ebsql_ref_from_hash from EBookSqlite is always returning NULL, even if instance
for given database was found in hash and its reference count was increased,
creating memory leak.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sqlite query planner does a really bad job here. It ought to realise
that it could do the searches on fields in folder_id directly from the
folder_id table, indices and all.
So recogise this case for ourselves and rephrase it so the query planner
doesn't do so badly. If it's just a logical 'OR' of a bunch of conditions,
some of which are auxiliary fields and some are not, then use a basically
hand-crafted query using UNION to make sure sqlite notices the fast way
to do it.
This takes the autocomplete query on my 237000-entry EWS GAL from about
1700ms to 6ms.
Yes, it's an icky special case and it *really* ought to be considered
a sqlite bug. But it's an important special case because the user is
waiting for it while they type and delays are really noticeable. And
it's a *big* win.
Discussed at
https://www.mail-archive.com/sqlite-users@sqlite.org/msg86350.html
https://www.mail-archive.com/sqlite-users@sqlite.org/msg86643.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the test case added in commit 5f9f5b52. We need to use LEFT JOIN
in the cases when we need to include records that have no auxiliary data, but
we really don't want to do that unless we need to because it's slow.
So add some logic to track it. The interesting question, as we process each
clause, is whether this clause is *mandatory* — does it *have* to match, for
a given record to show up in the final results? In the simple case of a
single 'AND', all its subclauses *are* mandatory. In the simple case of a
single 'OR', its subclauses are not (because a record can make its way into
the results without matching any specific subclause).
Since we need to err on the side of caution, the simplest approach was
just to bail and use 'LEFT JOIN' whenever we are referencing an auxiliary
field inside any 'OR'. But that was suboptimal in some cases where the
*same* auxiliary field was being tested twice. So we check whether all
subclauses of an 'OR' are on the same field, and we don't make it fall
back to LEFT JOIN when that's the case.
It helps that we never support NOT on auxiliary field checks, which would
make the whole thing a lot harder to think about...
|
| |
|
|
|
|
|
| |
and file_as
The Evolution address autocompletion uses these, and we really want it to
be fast. So enable indices on the *unlocalised* column by default.
|
| |
|
|
|
| |
This fixes a build break on some systems (for example Debian)
after changes in commit a2790163af4d3f375a778055d0e2699207dfd050.
|
