Ok. This is what the original sample config says:

// Main files source, backend driver which handles
// authentication and configuration of Chwala
// Note: Currently only 'kolab' is supported
$config['fileapi_backend'] = 'kolab';

So, this is not supported. Even if we implement this, it might be hard to use the Roundcube cache, because it requires ID of the user from users table.

root@xxx:/etc/roundcubemail# cat config.inc.php | grep fileapi

$config['fileapi_manticore'] = 'http://' . $_SERVER['HTTP_HOST'] . ':8080';
$config['fileapi_backend'] = 'seafile';
$config['fileapi_seafile_host'] = "https://files.xxxx.com";
$config['fileapi_seafile_ssl_verify_peer'] = false;
$config['fileapi_seafile_ssl_verify_host'] = false;
$config['fileapi_seafile_cache'] = 'db';
$config['fileapi_seafile_cache_ttl'] = '14d';
$config['fileapi_seafile_debug'] = false;

What is your config (only fileapi_* options)? When user logs into Chwala kolab driver is used to authenticate the user, so the user_id should be set in session.

I delete the config directory and rebuilt the mail box, every thing is back to normal.

Fixed.

No, wait. I see now that if you just visit the Resources tab doing nothing works, but if you visit the tab and add any resource to the event, then the organizer is not set in the Participants tab. T1484 fix is relevant here in a way that the organizer will be set anyway by the backend code. So, it's only frontend issue.

Re-opening, as this issue is not fixed in git.

Fixed in dfacbe01bca [master] and acc49b51fff [roundcubemail-plugins-kolab-3.2].

The best would be to see the whole message. You can remove private data.

Which parts of the XML are important? I can try to find it..

Kolab Plugins

Is there a chance we can see the original event data in XML form or as iCal export? Anyway, I suppose a needed fix here will be to remove the timezone string in brackets before passing it to the DateTime constructor.

Pykolab version is irrelevant here. What roundcubemail-plugins-kolab version? We had such an issue in the past, but it was hard to find the reason of it. I didn't hear about the issue recently, so maybe it's fixed or maybe not. To remove the tags you have to visit the Configuration folder and remove redundant objects. Do this in command line and then reconstruct the mailbox.

You are right. It's not implemented at all.

That's far easier than I thought. We already use save_file_content for special condition.
Let's just do that instead of sending the "Location:"-header too. This patch replaces
to one above. Would that work?

Just in case, more rpm versions:

So the actual issue seems to be if there are multiple recipients in the calendar invitation email then wallaced only creates the placeholder calendar event for the *first* recipient only.

Yes, i'm pretty certain this is the actual issue i've been seeing.

T2289 also says something about an issue with two recipients in To: header of an invitation email.

Sounds like a bug. So, this is the explanation of the initial issue, yes?

Another test was now done by sending a calendar invitation from Exchange 2010 to Kolab 16.1.

Oh, it seems --debug=8 syntax doesn't seem to work. This works instead:

This seems to be related to what email platform the sender is using. I tested the same procedure using google gmail.com as a sender, and kolab seems to work properly in that case, and updates the not-yet-accepted calendar invitation just like it should.

Yeah, with *_SAVE_AND_FORWARD it should probably update existing unresponded invitation event.

I accidentally created this as a bug, but it should be a feature request obviously.. and it seems I can't change the type myself?

Sounds like a duplicate of T1484.

Indeed according to RFC3696 and https://www.rfc-editor.org/errata_search.php?eid=1690 the address length limit is 254 characters.

It looks working now.

Just updated to Kolab 16.0.1 Release 12.1.el7.kolab_wf that this is still an issue when running in an LXC host!

Done in 99cd2b17522.

Actually the change need to be backported from master to roundcubemail-plugins-kolab-3.2 branch.

Yes, that'll load the file into memory - no problem for my users, because our files are small.

So, this would load the whole file into memory. Not something we'd like to do. So, first of all this probably should be an optional feature. Second, we should use seafile_request_observer to proxy the file content directly to the client. See seafile_file_storage::save_file_content(). Would you like to create a differential?

I came across this issue yesterday and the above patch appears to fix the problem for me. Please merge it into the iRony repository.

Yes, I agree it's not a software bug, but I propose to add some documentation about delegation to
https://docs.kolab.org/administrator-guide/using-the-kolab-web-administration-panel.html#users-administration
[which is empty right now]. Something like:

@adomaitis, committed 1d7e1237f2d to master. I don't know if there's anything more we can do here.

Confirmed. The problem here is that Outlook completely ignores the error we send in response to Sync request (after FolderUpdate). It should re-synchronize folders hierarchy according to the protocol specification.

Outlook and MS ... why I'm not surprised ...
let me know about the commit, I will try on my side.

@adomaitis I'm testing a fix and can't make Outlook display an error. I tried valid ActiveSync response with different error codes and even http error 500. In all cases Outlook just ignores the error and displays the folder as any other folder. So, while I'll commit the change it looks that it's not possible to tell Outlook the operation failed.

I tried installing Kolab 16 (from OBS as of today) on Jessie.
From all the above issues I confirm issues 2.1, 5 and 6.

Note to myself: See https://msdn.microsoft.com/en-us/library/gg651087(v=exchg.80).aspx for list of possible error status codes. Looks like code 3 might suit the best this case, but there are a few other cases that we might want to distinguish in error code.

Looks like you are right. There's a TODO entry in the folder creation code to throw exception on error, but it's not implemented and indeed no error is returned to the client. However, throwing an exception here is not enough, we need some more code in the Syncroton library itself to handle nicely the exception (returning properly formatted response instead of just a http error).

So same issue, with slightly different results: multiple commands sent together, which is allowed by the IMAP spec indeed, and then the client ends up waiting for responses that do not come as expected. Thanks for the report.

I've encountered another bug with guam. This time It's "eM Client" for Windows. I've activated the client debug log (in eM Client) and after sending a XLIST and SELECT command in TLS/SSL mode (it looks like the client sends 2 commands at once) the connections gets into some kind of stale mode. It's no longer working. Hard to tell without decrypting network traffic.

you've to seperate 2 things

My users still like the classic skin, but use only mail.
Anyway, we must not break people's setup, so we either need to modify the user settings
when upgrading or alert the admin and help him fix his system.
So we need to do more than just removing the skin.

See also T2208.

We should also remove the old classic skin. Some kolab plugins just does not work with classic skin.

Thanks - it works for me.

The dependencies were fixes yesterday. 2FA was introduced to Kolab:16 some days ago