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.

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.

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.

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

I was able ro reproduce the error:

1. I received a meeting invite.
2. I accepted the invite
3. I clicked Update in my calendar.
4. The webinterface showed saving for about 3 minutes

4.1 Mail and calendar was locked during this time

5. After recovery 3 minutes mail was working and the calendar was updated

Are there any other related patches? I searched and was unable to locate similar issues.

I'm not able to reproduce the issue anymore.

This was fixed in 66310b2fc46138.

Still considering what to be done with this.

Connecting with cli imap client "mutt" you can see this behavior because it always presents the full folder list (in the left folder view (patched) version as well when you want to switch the folders.

I could narrow it a bit down towards multiline input (IMO). The single commands are processed and filtered correctly. In the moment you or the client issues multiple IMAP commands at once guam isn't able to intercept and split it correctly.

I spoke too soon, after posting the above comment, the system would not allow me to log in. No calendar entries we made by anyone.

I have implemented T1988 patch, and the problem cannot be replicated.

@vanmeeuwen No, this is not a duplicate. The issue still persists with pykolab code from git-master. See Bifrost T16075 for the same issue.

This should be documented here, shouldn't it?
https://docs.kolab.org/upgrade-guide/kolab-16.html

This is likely a duplicate of T1988

The patch for the plugin package in Kolab:16 is waiting for review

I have the same syptoms on a fully updated kolab16 on centos7.
Rebooting the sever starts things going for a while until ldap is blocked again.
If it happens Roundcube login does not work and sending mails via kontact is blocked.

Hi machniak, the current build 16 that we are using already has the fix:
https://git.kolab.org/rP54cb493d655bb67719572acd934994161c3751af

We need more recent roundcubemail-plugins-kolab package.

According to Florian Eder, this has been tested and is working.

I tested on a system where I copied the sound files to the correct location some earlier, and that's why the test seamed to work but unfortunately this is not solved. The sound files are still not available at the correct path after package new/first installation.

Built. Tagging now.

Rebuilding for Kolab 16
Rebuilding for Kolab Enterprise 14

Built for Winterfell
Submitted to Kolab 16
Submitted to Kolab Enterprise 14

tested -> passed -> resolved

opened a new bugzilla #5461 issue to bring this special packaging problem back into focus

Are we likely to see SPECIAL-USE (RFC 6154) working and enabled on Kolab Now, as it is currently not enabled. This would definitely make email client setup easier and there would be no effort required for the non-technically inclined user. I reckon this would add some value to Kolab Now.

closing https://issues.kolab.org/show_bug.cgi?id=5028 now depends on this task only