Done in 99cd2b17522.

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

To reproduce the issue just try to rename a file over WebDAV.

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?

@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.

@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).

As you can see in the Details section above, it is in develop.

See also T2208.

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

@seigo, I started working on a 1:1 chat. Creating and using a chat is simple. Problem is with invitations/notifications. I suppose we'd need some kind of event system. Consider scenario:

1. UserA first time wants to talk with UserB
2. UserB is notified about "incoming chat". He joins the conversation.
3. UserB disconnects, closes the chat window. Then connects again.
4. UserA want's still to talk with UserB again.

Two connections with the same user and context should "share" the status, i.e. the status should always be the same for them. If you change status in one window it should change in other windows for the same user+context.
I don't see how a separate channel can help here. Maybe using system:<context> as a channel name would help. I don't know, Presence will still see these two connections as separate. No? Feel free to fix this.

@seigo, what do you think about use of https://github.com/meh/amnesia ?

Presence maybe is nice chunk of code, but still we need to implement:

1. last status persistence. I'm not even sure how to implement that, what's the "last status" of the user if he uses multiple clients? But I think it would be reasonable to not force "online" status when user connects to the service. Or should we only store status in a session? So only connection with expired session will set the status to "online".
2. the context handling and best availability status setting should be done server-side, for privacy and performance reasons.
3. if some user is not connected no one will see him as an existing user and will not be able to invite him - we need a user list on the server that is not based on Presence.

Don't update presence on invalid status

Implement more status values (T2124)

See D363. Still I prefer to use system channel for presence operations. Additionally implemented "client context". Still does not implement status persistence.

Proposed fix:

-- a/pykolab/auth/ldap/__init__.py
+++ b/pykolab/auth/ldap/__init__.py
@@ -1683,6 +1683,8 @@ class LDAP(pykolab.base.Base):
                     entry[mailserver_attribute]
                 )

We already use Phoenix.Token for user authentication tokens. But I don't understand for what you propose to use it. User metadata? I suppose not for anything else?

@seigo, I'm having trouble with this. Would you mind taking a look? I thought it will be a simple change in system_channel.ex, but I can't make it working.

We already use (authenticated) system channel for that and I think it should/can be used still. I just wasn't sure channel about data persistence or channel data size limitations. So, it looks that if we use the system channel all we need is to properly handle user joins to the channel. I'll go this route for now.

@seigo, I'm not sure we can do it without SQL, how about invitations? I'm thinking of a case of "I'm logging in, give me all pending invitations". I don't think we can store invitations inside a chat. I'm used to use relational databases and can't imagine how to use key/value store here.

This is already implemented. Enable zipdownload plugin and make sure php-zip is installed.

I'm unable to reproduce this with Roundcube Calendar. So, it might be already fixed or the bug is in iRony.