Positive-prefixed TRIGGER VALARM components are being ignored

[brong]

From: Alfie John Bugzilla-Id: 3836 Version: 2.4.17 Owner: Ken Murchison

[brong]

From: Alfie John

From the RFC, the TRIGGER is a DURATION value type so it's format is:

dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)

dur-date = dur-day [dur-time] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1DIGIT "W" dur-hour = 1DIGIT "H" [dur-minute] dur-minute = 1DIGIT "M" [dur-second] dur-second = 1DIGIT "S" dur-day = 1*DIGIT "D"

The following TRIGGER values do what is expected:

-P3W4DT5H6M7S P3W4DT5H6M7S

When TRIGGER is "+P3W4DT5H6M7S", the TRIGGER calendar component is missing from the response.

[brong]

From: Ken Murchison

I'm not sure I understand what/where the problem is. Which response?

As far as I recall, the Cyrus code doesn't explicitly touch any of the VALARM properties. Perhaps this is a bug in libical?

Can you provide more context?

[brong]

From: Alfie John

When I do a PUT using the following data:

BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//FastMail/1.0/EN BEGIN:VEVENT DESCRIPTION: DTSTAMP:20140114T002112Z DTSTART:20140114T002111 LAST-MODIFIED:20140117T170000Z LOCATION: SEQUENCE:0 SUMMARY:Test event TRANSP:OPAQUE UID:test123 BEGIN:VALARM UID:test123Alarm TRIGGER:-P3W4DT5H6M7S ACTION:EMAIL END:VALARM END:VEVENT END:VCALENDAR

I get the same data back when doing the following REPORT:

<C:calendar-query xmlns:A='http://apple.com/ns/ical/&#39; xmlns:C='urn:ietf:params:xml:ns:caldav' xmlns:M='http://messagingengine.com/ns/calsync&#39; xmlns:D='DAV:'><D:prop><C:calendar-data/></D:prop><C:filter><C:comp-filter name='VCALENDAR'><C:comp-filter name='VEVENT'/></C:comp-filter></C:filter></C:calendar-query>

When changing the TRIGGER calendar component to:

TRIGGER:P3W4DT5H6M7S

I get the following calendar data from the REPORT:

BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//FastMail/1.0/EN BEGIN:VEVENT DESCRIPTION: DTSTAMP:20140114T002112Z DTSTART:20140114T002111 LAST-MODIFIED:20140117T170000Z LOCATION: SEQUENCE:0 SUMMARY:Test event TRANSP:OPAQUE UID:test123 BEGIN:VALARM UID:test123Alarm TRIGGER:-P3W4DT5H6M7S ACTION:EMAIL END:VALARM END:VEVENT END:VCALENDAR

So far, everything is what is expected. However, if the TRIGGER is changed to:

TRIGGER:+P3W4DT5H6M7S

then the REPORT returns the following:

BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//FastMail/1.0/EN BEGIN:VEVENT DESCRIPTION: DTSTAMP:20140114T002112Z DTSTART:20140114T002111 LAST-MODIFIED:20140117T170000Z LOCATION: SEQUENCE:0 SUMMARY:Test event TRANSP:OPAQUE UID:test123 BEGIN:VALARM UID:test123Alarm ACTION:EMAIL END:VALARM END:VEVENT END:VCALENDAR

Notice now that the TRIGGER line is now missing.

[brong]

From: Alfie John

Typo (changing sign in the calendar component). That should have been:

When changing the TRIGGER calendar component to:

TRIGGER:P3W4DT5H6M7S

I get the following calendar data from the REPORT:

BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//FastMail/1.0/EN BEGIN:VEVENT DESCRIPTION: DTSTAMP:20140114T002112Z DTSTART:20140114T002111 LAST-MODIFIED:20140117T170000Z LOCATION: SEQUENCE:0 SUMMARY:Test event TRANSP:OPAQUE UID:test123 BEGIN:VALARM UID:test123Alarm TRIGGER:P3W4DT5H6M7S ACTION:EMAIL END:VALARM END:VEVENT END:VCALENDAR

[brong]

From: Ken Murchison

Hmm. That's odd. I'm assuming that libical is removing it, but I will do some testing.

Can you check the actual data stored on disk to see if the TRIGGER property is missing? I'm wondering if its getting removed via the ical/xcal/jcal translation layer.

[brong]

From: Alfie John

> Can you check the actual data stored on disk to see if the TRIGGER property is missing? I'm wondering if its getting removed via the ical/xcal/jcal translation layer.

Sure thing.

When the TRIGGER is -P3W4DT5H6M7S or P3W4DT5H6M7S, the TRIGGER is stored on disk.

When the TRIGGER is +P3W4DT5H6M7S, the TRIGGER is missing on disk.

[brong]

From: Ken Murchison

Here's what I found so far. Its definitely libical (v0.48 in my case) that doesn't like the TRIGGER value. Here's what's get stored if I leave the libical error properties in the data:

BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//FastMail/1.0/EN BEGIN:VEVENT X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: DTSTAMP:20140114T002112Z DTSTART:20140114T002111 LAST-MODIFIED:20140117T170000Z X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for LOCATION property. Removing entire property: SEQUENCE:0 SUMMARY:Test event TRANSP:OPAQUE UID:test123-1 BEGIN:VALARM UID:test123Alarm X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:Can't parse as TRIGGER value in TRIGGER property. Removing entire property: +P3W4DT5H6M7S ACTION:EMAIL END:VALARM END:VEVENT END:VCALENDAR

The following (untested) patch to icalduration.c should fix it:

--- icalduration.c.orig 2014-01-15 10:23:46.546643215 -0500 +++ icalduration.c 2014-01-15 10:24:27.668682294 -0500 @@ -93,6 +93,12 @@

switch(p) 
    {

• case '+': {
• if(i != 0 || begin_flag == 1) goto error;
• break;
• }

• case '-': {
  if(i != 0 || begin_flag == 1) goto error;

[brong]

From: Alfie John

Thanks for the patch. Tested and yes it fixed the issue :)

[brong]

From: Ken Murchison

Thanks Alfie. I have reported the bug and the patch to the libical folks.

[brong]

Closing: was RESOLVED in import