Still can't find the way to reproduce the issue. Another source informed us that it had the same issue and there was CalDAV client involved. I reviewed the code and I don't see what actions could lead to such invalid timezone entries. Here's a patch that we could use, but I think the issue is in another place:

--- a/plugins/calendar/calendar.php
+++ b/plugins/calendar/calendar.php
@@ -1974,6 +1974,8 @@ class calendar extends rcube_plugin
    */
   private function write_preprocess(&$event, $action)
   {
+    $event['start'] = preg_replace('/\s*\(.*\)/', '', $event['start']);
+    $event['end']   = preg_replace('/\s*\(.*\)/', '', $event['end']);
     // convert dates into DateTime objects in user's current timezone
     $event['start']  = new DateTime($event['start'], $this->timezone);
     $event['end']    = new DateTime($event['end'], $this->timezone);

That looks like simple mistake in the code. Fixed in rRPKc2e8cc16abf3.

I was investigating a similar case - create event in Gmail and invite 2 attendees - one for user with Outlook and one for user in Roundcube. Both accept the invitation, but user who accepted it in Roundcube is not marked with a check box in Gmail.
it turns out, that Roundcube sends possibly wrong DTSTAMP in meeting acceptance iTip. Comparing responses I noticed that original invitation from Gmail has

METHOD:REQUEST
DTSTAMP:20170627T054332Z
CREATED:20170627T054331Z
LAST-MODIFIED:20170627T054331Z

Acceptance iTip coming from Outlook has:

METHOD:REPLY
CREATED:20170627T054452Z
DTSTAMP:20170627T054452Z
LAST-MODIFIED:20170627T054452Z

But Roundcube sends iTip with:

METHOD:REPLY
DTSTAMP:20170627T054331Z
CREATED:20170627T054331Z
LAST-MODIFIED:20170627T054331Z

It is one second behind from DTSTAMP value in invitation. If I send exactly the same response as Roundcube did, but modify DTSTAMP to be at least the same value as it was in invitation, then Gmail records the status of the attendee.
RFC5545 says that:

In the case of an iCalendar object that specifies a "METHOD"
property, this property differs from the "CREATED" and "LAST-
MODIFIED" properties.  These two properties are used to specify
when the particular calendar data in the calendar store was
created and last modified.  This is different than when the
iCalendar object representation of the calendar service
information was created or last modified.

I'm not sure I fully understand what they want to say here, but to me it looks like:

• DTSTAMP in REPLY should be later than it was in REQUEST
• DSTAMP should be different from CREATED and LAST-MODIFIED

1. So, the iTips differ not much. I don't think CLASS:PUBLIC is relevant.
2. I think it's possible. When the event time changes client could request "re-sheduling". You'd need to see what's in G's iTip in step 4.

In T2504#37355, @machniak wrote:

We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.

Back to your questions:

1. No idea. Check Itip payload.

Event which doesn't make GMail Calendar record attendee status as accepted

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN
CALSCALE:GREGORIAN
METHOD:REPLY
BEGIN:VEVENT
UID:i698fn56cjct6tvjt3sfa2m6j0@google.com
DTSTAMP:20170621T091446Z
CREATED:20170621T091446Z
LAST-MODIFIED:20170621T091446Z
DTSTART:20170622T040000Z
DTEND:20170622T050000Z
SUMMARY:KS Demo =C4=97
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
SEQUENCE:0
TRANSP:OPAQUE
STATUS:CONFIRMED
ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA=
NT;CUT
 YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld
ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com
END:VEVENT
END:VCALENDAR

Event which makes GMail record attendee status

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN
CALSCALE:GREGORIAN
METHOD:REPLY
BEGIN:VEVENT
UID:i698fn56cjct6tvjt3sfa2m6j0@google.com
DTSTAMP:20170621T091716Z
CREATED:20170621T091446Z
LAST-MODIFIED:20170621T091716Z
DTSTART:20170622T040000Z
DTEND:20170622T060000Z
SUMMARY:KS Demo =C4=97
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
SEQUENCE:0
TRANSP:OPAQUE
STATUS:CONFIRMED
CLASS:PUBLIC
ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA=
NT;CUT
 YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld
ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com
END:VEVENT
END:VCALENDAR

We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.

FYI, Collabora Online 2.1.2 added support for avatars and custom button. So, technically it should be possible to move all our functionality into the editor frame.

Search for files with content "FLE Daylight Time" in /var/spool/imap/domain/ and provide a sample file.

Any tips how to best debug this issue?

Page refresh should fix the issue. This is a regression that is not so simple to fix. My first take on this failed.

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.

Fixed.

The fix is in roundcubemail-plugins-kolab repo.

But this object has valid dates. So, how do I reproduce the issue?

I hope I didn't screw up the xml while removing private info.. but here goes:
http://pasik.reaktio.net/kolab-webmail-calendar-internal-server-error.xml

No, K16 is enough

Fixed in:

• chwala e412536b1b6 [master] and 04ff2737dc [chwala-0.4].
• roundcubemail-plugins-kolab f357819dd0 [master].

The issue with emails is a user-confusion issue: you get an email with an attachment, you save that attachment "to the cloud", and now the time is oddly different than the email. So it isn't that there is a bug with emails, but that the time differences cause problems for users.

I'm not sure what issue do you have with email, but files are indeed stored with timestamps in UTC. The plugin displays the date as-is provided by chwala. It will be chwala's responsibility to convert it to user timezone (if provided). The timezone would need to be passed by Roundcube to chwala first.

I can't reproduce the issue by importing the .ics file. Could you provide the object in xml format (i.e. the message from imap folder)?

Sorry took a while, but now it happened again..:

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.

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.

Just in case, more rpm versions:

Sounds like a duplicate of T1484.

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

Looks like none of libkolabxml and plugins: libkolab and calendar support BYSETPOS. As a quick fix we should probably allow two simple and most common cases of "first weekday" and "last weekday" by converting them to correct BYDAY property.

I can confirm this. There are at least two issues here:

1. allday flag for exceptions is forced to be the same as main event. This can be fixed with this:

-- a/plugins/libkolab/lib/kolab_format_event.php
+++ b/plugins/libkolab/lib/kolab_format_event.php
@@ -291,7 +291,9 @@ class kolab_format_event extends kolab_format_xcal
         }

@vanmeeuwen, So we have a case with no delegation, but with a shared folder where user (with write rights) deletes an event. Considering my comment here https://git.kolab.org/T1357#27566 and the next one, what would you propose? Note that we first have to solve this independently from what wallace does, i.e. define what iTip messages are sent and when, should we use SENT-BY field, etc. Then how wallace would handle that is another story.

Any news for this issue?

Promoted to Bifrost#T18595.

This works for me. So, it may be some timing issue. Note that these notifications are not "instant", they are "pulled" in one minute intervals (timer starts when the page is loaded).

If you're in the File section of the web client, invitations about being invited to a collaborative session show up.

What File dialog? Could you be more precise? The notifications should be displayed in all Roundcube windows. That's how it worked.

This ticket can be closed. It was a combination of packages/releases that didn't played together.

Looks like this bug only happens in the old version. The most recent plugins package from Winterfell doesn't have this issue

I foun the broken commit rRPK1f88231db9fd0edca6e5b09c38e150216d760341. Fixed.

These "untranslated" messages come form wallace. We need to take care the solution works also for environments where invitation policy is not used at all or is used in various other modes.

Played around with Delegation and Shared Folder to test the behaviour of both functions.

Well, collabora devs implemented features that allowed to implement Kolab toolbar as described in [1] (an as on the screenshot). Still, we didn't really decide that it's a better approach. It was simpler to implement.

Could you update this task with the results of the discussions you have had with Collabora devs? Thanks!

Yes, for now lets just settle on CloudSuite.

Looks like my IMAP infrastructure doesn't support METADATA or ANNOTATEMORE... I think this is why we are using database_driver

Yes I am using database_driver. I don't remember why...

Do I understand correctly that you use database driver?

Current implementation gives prio to Collabora.

I started to package endroid-qrcode for Debian and saw that there is a new upstream release 1.6.5 available. The changelog has:

Done.

Tested and indeed there's a problem with this scenario. When handling an iTip we search for the event only in folders in personal and shared namespace. Here we have a folder in other user namespace. So, in [8] as well as in [6] the event cannot be found.

There were some related changes in git, some not packaged yet. I'll test git-master, to see if any of these issues can be still reproduced.

Groups with email address specified will not be expanded with their members.

Better fix submitted in D242. Waiting for approval

A test with TOTP was successful.

Hm, there seems to be some confusion between method (driver to use) and id (yubikey:<hexcode>). the plugin tried to load config['kolab_2fa_yubikey:<hexcode>'] which obvously fails. The following patch (against Winterfell) seems to fix it for me - but I didn't test HOTP or TOTP token. And already added yubikeys had to be removed and readded.

The configuration options should already make their way into the $config member of the Yubikey class. They are read in kolab_2fa::get_driver(), passed through Kolab2FA\Driver\Base::factory() all the way to Kolab2FA\Driver\Base::init() where they are merged with $this->config. It's to be investigated why the following line in Base.php doesn't work as expected:

$this->config = array_merge($this->config, $config);

Thank you for the information. We will review it and dig a little deeper into this issue (shared folder vs. delegation).

Actually RFC5546 specifies a special case of acting on behalf of an organizer. So, I suppose we could assume that having write rights to calendar is such a case. Can't we?