Page MenuHomePhorge

Inconsistent behavior while accepting invitations in roundcube
Closed, ResolvedPublic

Description

Not totally sure what is relevant here, but:
wallace-0.8.7-1.1.el7.kolab_16.noarch
roundcubemail-1.2.5-8.1.el7.kolab_16.noarch
roundcubemail-plugins-kolab-3.3.1-3.1.el7.kolab_16.noarch
roundcubemail-plugin-calendar-3.3.1-3.1.el7.kolab_16.noarch
Wallace is configured with kolab_invitation_policy = ALL_UPDATE, ALL_MANUAL.
Scenario:
User G is Gmail Calendar user, User K is Kolab user using Roundcube.

  • User G creates an event in GMail Calendar and invites user K
  • User K receives invitation and clicks "Accept". Event is recorded in Kolab calendar. In Kolab user K is marked as "accepted".
  • User G receives status update from user K. It says that "K accepted the invitation", however GMail calendar doesn't show that. It shows that 1 response is still pending.
  • User G changes the event (change location or extend the event to last one hour more). GMail sends out the update of the event.
  • Because of wallace setting, K users's calendar is updated automatically, no update emails received by K. That is fine, but clicking the event in Roundcube Calendar view suggests to act upon the event (accept or decline).
  • User K accepts the event and user G gets the acceptance. This time GMail Calendar shows that K user has accepted the event (no acceptance is pending).

Questions:

  • how come accepting event invitation in email and in event view in Roundcube are treated differently by GMail?
  • is it correct that automatically accepted event by wallace is not marked as accepted in Roundcube?

Details

Ticket Type
Task

Event Timeline

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.
  2. I don't see "automatically accepted event" in this scenario (and wallace settings).

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
  1. I don't see "automatically accepted event" in this scenario (and wallace settings).

I wanted to say: is it correct that automatically updated event by wallace is not marked as accepted in Roundcube, given that it was accepted before?

  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.

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
machniak claimed this task.

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