The previous behaviour did not work in the addressbook if more than 500
results were provided, because nothing turned the uid only fetch into
the full data, resulting in "empty" result records.
This solution seems to work fine for the cases tested and avoids having
to completely different codepaths based on a number of records found.
The code does "move object then read it" and "read it" was failing
because the folder cache wasn't up-to-date. We force re-synchronization
by reseting the state properly after move().
Summary: Use QRESYNC, get rid of "scheduled" cache reset, other small improvements
Reviewers: #roundcube_kolab_plugins_developers, vanmeeuwen
Reviewed By: #roundcube_kolab_plugins_developers, vanmeeuwen
Subscribers: vanmeeuwen, #roundcube_kolab_plugins_developers
Differential Revision: https://git.kolab.org/D1726
https://issues.kolab.org/show_bug.cgi?id=4067 and (Bifrost#TT20881)
It happens that IMAP folder may contain many objects with the same UID.
The precise reason for this is unknown, but it can be e.g. a faulty
client or an error between "create a new object instance" and "remove the
old one". It causes various issues when editing such objects.
With the change we assume that the most recent object (with max. IMAP UID)
is the one that should be used and all the older instances will be removed
automatically.
Summary:
Fixes race-conditions between Kolab folders and Roundcube core
where skip_deleted/threading could be set for operations outside
of Kolab plugins, causing e.g. inability to see \Deleted messages.
Fixes T1145.
Reviewers: #roundcube_kolab_plugins_developers, vanmeeuwen
Reviewed By: #roundcube_kolab_plugins_developers, vanmeeuwen
Maniphest Tasks: T1145
Differential Revision: https://git.kolab.org/D112
Before the change to get an object by UID we first resolve UID to IMAP-UID
and then fetch the object data by IMAP-UID - two select queries. Now we
directly select the data by UID.
- store and compare the number of objects stored after last sync
- use a (configurable) refresh interval and periodically force re-sync
ATTENTION: requires database schema updates
This change will make the synchronization process abort before the time limit is reached.
The folder is not flagged as fully synchronized and subsequent requests will continue the synchronization.
Application scripts can read the public 'sync_complete' property and initiate a next sync request.
