- User Since
- Feb 15 2016, 4:41 PM (215 w, 7 h)
Jan 9 2020
Patch seems to work. I haven't seen this issue after applying the patch. Thanks a lot!
Nov 8 2019
@machniak Thanks a lot! I'll try the patch. This .ics arrived from Microsoft Exchange Server 2010 (based on the PRODID field in .ics).
Nov 6 2019
Oct 12 2018
Could anyone please review this patch? it sounds like an important fix to have.
Jun 30 2017
Hmm, the user who has been reporting this issue uses some mobile email client in addition to the kolab roundcubemail, so it *might* be related to mobile client, but I'm not sure really..
Any thoughts/plans about fixing this issue? Users hit this issue very often, because currently kolab auto-updates only the *first* recipient calendar..
Jun 7 2017
Any tips how to best debug this issue?
May 31 2017
That's the problem. The error in question hasn't happened to me, so i don't know the exact steps to reproduce. What I've heard is that "it just happens automatically". When the recipient gets the calendar invitation email, the placeholder event is automatically created in the calendar (per kolab policy settings), and when the recipient user tries to accept/reject the invitation from the kolab roundcube webmail *calendar* application he gets the Internal Server Error and the PHP Fatal Error and the stack trace I posted can be found from the logs.
May 29 2017
I hope I didn't screw up the xml while removing private info.. but here goes:
May 23 2017
Sorry took a while, but now it happened again..:
Apr 1 2017
Which parts of the XML are important? I can try to find it..
Mar 18 2017
Just in case, more rpm versions:
Mar 15 2017
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.
Mar 14 2017
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:
Mar 13 2017
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.
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?