GitLab

Also looup -> look up

ImapInterval does not allow begin() > end().

FIXED-IN: 4.14.3
BUG: 339172

If the result of UID SEARCH is too big Exchange just disconnects. To work around
this the UID SEARCH is splitted into smaller chunks (I choose 2000 arbitrarily).

First I wanted to do this for all servers but I've a server where UIDs go up to
1 billion which results in half a million SearchJobs. So I do the splitting only
for Exchange servers. I don't know if there is a better way to recognize Exchange
servers than to look at Session::serverGreeting()?

There are still issues with Exchange but at least for me it's usable again.


CCBUG:  339393
REVIEW: 120644

triggerCollectionExtraInfoJobs was removed in 945a5cca but the
corresponding change never made it to the Kolab resource, thus it would
stop when trying to run a non existent task.

Notice that this may be a stop-gap solution (I don't know the code too
well) but seems to work.

CCMAIL: dvratil@redhat.com
CCMAIL: chrigi_1@fastmail.fm

This reverts commit d6330e59.

If the task get's externally (not by the task itself) cancelled
(i.e. by a dropped connection), the task my be running a job and once it
returns i.e. cancel the task again.

This results in ResourceBase methods getting called while no task is active,
ending in an assert.

This patch simply isolates ResourceTask once cancelTask has been called.

ResourceBase does that now for us. We do have to use synchronizeCollectionAttributes
instead of the custom task though.

If we're unlucky enough that we receive a disconnect call before a session
has been declared ready, we end up declaring the about to be deleted session.
This then results in a dangling pointer and eventually in a crash.

Needed for at least Zimbra that doesn't like
having items files named by anything else but
the incidence UID and that redirects. KIO
does not supply the username / password (as
it should), but we have no way to ask the user
for confirmation.

Many thanks to Benjamin Girault for the initial
debug, patch and testing.

BUG: 339634

Although not specified in RFC, IMAP servers usually have some limit on maximal
length of a command send by clients. This is best visible in case of ChangeItemsFlagsTask,
which would create an insanely long STORE command when user marked as read
thousands of emails at once.

To prevent servers from rejecting our requests, we split large STORE requests
to multiple smaller ones, each of 2000 UIDs at most. 2000 sounds like a good
compromise between not hitting it too often (i.e. users usually mark as read
few emails at once, hundreds at best) and not hitting the server-side limits
(every server out there should handle 2000 UIDs in a request). This number
can be tuned later of course if we find out it's too much/not enough.

REVIEW: 120446
BUG: 339565
FIXED-IN: 4.14.2

Removing emails means appending the \Deleted flag, so RemoteItemsTask is
just a simpler version of ChangeItemsFlagsTask with hardocded flag to append.
To avoid code duplication and make use of flags-related fixes in ChangeItemsFlagsTask,
we can just use that instead of RemoveItemsTask.

REVIEW: 120447
CCBUG: 339565

Fix by lftabera-at-yahoo.es

BUG: 339327

(or set error text ourselves, when it doesn't come from an underlying job)

FIXED-IN: 4.14.2
BUG: 339169