Maybe something like this would help:
diff --git a/lib/Auth/LDAP.php b/lib/Auth/LDAP.php index f5e33b2..2db826e 100644 --- a/lib/Auth/LDAP.php +++ b/lib/Auth/LDAP.php @@ -122,6 +122,12 @@ class LDAP extends Net_LDAP3 { $this->config_set("root_dn", $root_dn); }
I feel uneasy about using binary data in sql queries, without special blob handling, but I guess it should work until we're proven otherwise.
The net-ldap3 warning was already fixed in https://git.kolab.org/rPNL39a754269fe6e5d94b0fe87215e89232876bda01.
php-net-ldap3 is our main workhorse for ldap connections, php-net-ldap2 is a dependency there for a one or two features in use.
No, I tried registering handlers for Queue::JobProcessing and Queue::jobProcessed events via AppServiceProvider::boot(). The handlers were triggered, but the job object there is not the same as our job, and access to the job data requires instantiating the actual job from a serialized object string. Possible, but ugly.
A test for IMAP::clearMailbox() would be appreciated.
Looks to me that the folders passed to the command need to be in Cyrus internal format user/{$localpart}/{$mailbox}@{$domain}. That's not very user-friendly. Also tests for the new IMAP methods would be welcome, less important for the command itself.
It's good enough, but I added some comments.
Looks good, but for consistency both queries should use tenant context and the same way of comparing user status.
Maybe looking at syncroton_content.creation_synckey value would sometimes be useful. Maybe list uids of messages synced in the last batch (SyncKey).
I see that MoveItems has a global Status (that we do not use) and per-item Status. https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-ascmd/acae4033-b4f9-4f2a-8d83-51e097eb3b90
FYI. Not necessarily better, but Roundcube already supports ENV by default. See https://github.com/roundcube/roundcubemail/blob/3e4894ee061e884099f1acc26f34697fbd8b5f8e/program/lib/Roundcube/rcube_config.php#L386