Page MenuHomekolab.org

Possibly a bug with rescheduling event via CalDav
Closed, ResolvedPublic

Description

It looks like that even though SCHEDULE-AGENT=CLIENT is specified iTip, event rescheduling generates "Cancel event" email to attendee.
Steps to reproduce:

  • create new event and make sure that ATTENDEE property in iTip has SCHEDULE-AGENT=CLIENT is specified. No invitation should be delivered by iRony. That is correct.
  • move the event to new time slot. See that event ATTENDEE property is specified in the same way, the "Canceled" email was sent.

For my experiments I did that with curl:

curl -v -T ./caldav.itip -u kolab.systems@domain.tld:password \
    -H "User-Agent: Curl/2.22" \
    -H "Content-Type: text/calendar; charset=utf-8" \
    -H "Host: kolab.domain.tld" \
    -H "Connection: close" \
    https://kolab.domain.tld/dav/calendars/kolab.systems%40domain.tld/64a95414-51d7-46f8-ade0-5079cc40ca63/0000000001-d661-45c9-9ecf-42376663f986.ics

The iTip I used:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ddaysoftware.com//NONSGML DDay.iCal 1.0//EN
BEGIN:VTIMEZONE
TZID:FLE Standard Time
BEGIN:STANDARD
DTSTART:19701025T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYHOUR=4;BYMINUTE=0;BYMONTH=10
TZNAME:FLE Standard Time
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19700329T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYHOUR=3;BYMINUTE=0;BYMONTH=3
TZNAME:FLE Daylight Time
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=ks@domain.tld;ROLE=REQ-PARTICIPANT;RSVP=TRUE;
 SCHEDULE-AGENT=CLIENT:mailto:ks@domain.tld
CLASS:PUBLIC
DESCRIPTION:Test\nNew time slot
DTEND;TZID=FLE Standard Time:20170704T193000
DTSTAMP:20170630T142853Z
DTSTART;TZID=FLE Standard Time:20170704T180000
LOCATION:no location
ORGANIZER;CN=Kolab Systems;SCHEDULE-AGENT=CLIENT;SCHEDULE-STATUS=1.1:mailto
 :kolab.systems@domain.tld
PRIORITY:5
SEQUENCE:1
SUMMARY:AAAAAAAAAAAAAAAAAAAAA
TRANSP:OPAQUE
UID:0000000001-d661-45c9-9ecf-42376663f986
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR

To move event to new time slot I was just changing DTSTART and DTEND
If I read correctly RFC6638 says that if SCHEDULE-AGENT=CLIENT, then all event invitations and updates should be handled by the client not the server.

Details

Ticket Type
Task

Event Timeline

adomaitis added a project: iRony.
adomaitis added a subscriber: iRony Developers.

However, https://tools.ietf.org/html/rfc6638#section-3.2.1.2 says that CANCEL is sent when an event was modified and previous scheduling was done by the server (default if SCHEDULE-AGENT is not specified). So, probably the issue is in recognizing the previous state.

Could be. I've tried to create new meeting and looking at the Caldav I see that ATTEDEE is:

ATTENDEE;CN=ks@fsi.io;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:
 mailto:ks@fsi.io

So looks like SCHEDULE-AGENT is gone.

I verified with the code that if the original event would specify SCHEDULE-AGENT=CLIENT for the attendee it would be properly recognized by SabreDAV classes and the CANCEL would not be sent. So, what we need is to store this initial SCHEDULE-AGENT value in custom properties of Kolab format (or extend the format of https://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Attendee).

@vanmeeuwen, do you think that's the only option? Maybe it would make sense (though breaking RFC) to disable these CANCEL invitations from CalDAV service by config? I mean, no matter what client has been used to create the event we do not send them.

machniak closed this task as Resolved.
machniak claimed this task.

Fixed by 0c02d0d45c6 in roundcubemail-plugins-kolab [master].