It's a bit of a mess indeed.
I think it's not needed because default_port will be ignored if the port is part of the host string.
I'm unsure how to clean this up without breaking anything, so I'll just stick to doing what we do elsewhere.

Adjust to doing the same as iRony/syncroton

• Support saving task tags as categories

On the other hand we use default_port everywhere, and we probably should not. I'm just wondering, why that second part of this change is not needed in Syncroton and iRony, but is in Chwala.

Ha, I missed we use parse_host() in select_host(). So, that whole change in login() seems redundant.

This could be simplified by use of rcube_utils::parse_host() which is what we already do in Syncroton and iRony.

The imap user is being created from UserSeeder in the demo config. You have to remove that part. Also, maybe the command should be db:init or data:init, but just init is also fine.

Tested with ci/testctl deploy

It's all right. The extra headers could also have been passed through the DAV\Search "interface", I suppose.

Smart.

Manually tested

Works now.

The client could send some HTTP header, e.g. X-Skip-Attachments: true. Since we control both sides this seems to be the best idea to me. From what I see the client could also advertise itself as "User-Agent: Lightning/1".

• Performance: Use lighter rcube_message_header instead of rcube_message

Adding methods to backend interface implementation requires some more code. Phpstan says:

Line   lib/ext/Syncroton/Command/FolderSync.php                          
------ ------------------------------------------------------------------ 
 295    Call to an undefined method Syncroton_Backend_IFolder::exists().

• Fixes regarding syncroton API for tags

• Small doc fix

• CS fixes
• ANNOTATE driver
• Improvements
• SQL driver fixes

TODO:

• FIgure out if this is actually compatible with existing deployments
• Do we have to use withEnvTenantContext in various places?

Call the right command

Missed something

I suppose doing this during a migration is a bad idea because this also depends on the configuration to be available.

Deduplicate the creation of the client

Fix rebase error

Don't create the user, test the supposedly existing one instead

Addressed comments

In D5046#63456, @machniak wrote:

BTW, none of the other registered passport clients are added via the migration. Maybe they should too. However, as all of them depend on existing-in-config client secrets and Ids, I'm still not sure migration is the correct place. Maybe we should have something like a "global seeder".

BTW, none of the other registered passport clients are added via the migration. Maybe they should too. However, as all of them depend on existing-in-config client secrets and Ids, I'm still not sure migration is the correct place. Maybe we should have something like a "global seeder".

Check for existence first

We call the seeder after migration, so the seeder will fail because the record already exists.

We should probably contemplate a standard mechanism for cases like this, so we don't copy paste these definitions around.

move the migration to the environment specific overlay