417629 - Import ICS file to CalDAV server fails to handle recurrence-id correctly

Status: VERIFIED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Andrew Daviel]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: sunbird 0.8pre Gecko/20080212

When importing an ICS file (created with Sunbird) into a CalDAV calendar,
where there is one instance of a recurring event which has been moved to a different day, that instance will be incorrectly shown on its original, non-moved day (ignoring the recurrence-ID).

When importing the same ICS file to a local calendar, the event is imported correctly.
Tried with Bedework, DavICAL and Dingo

Reproducible: Always

Steps to Reproduce:
1. subscribe to CalDAV calendar "on the network"
2. Import t0-weekly.moved1.5.ics

Actual Results:  
Event shows at 10am on May 2 2007

Expected Results:  
Event shows at 10am on May 3 2007

The recurrence-ID instance is never written to the CalDAV server.

Comment 1

[Bruno Browning]

Hi Andrew-
Any chance you could attach a testcase .ics that shows the bug?

Comment 2

[Bernard Desruisseaux]

Attachment: Recurring day event for Easter from 2008 to 2020

When importing this file into a CalDAV calendar, Lightning only submits the
master recurring component to the server, that is:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20080411T171530Z
LAST-MODIFIED:20080411T171532Z
DTSTAMP:20080411T171532Z
UID:easter-d49a4c018a1a
SUMMARY:Easter
RRULE:FREQ=YEARLY;COUNT=13;INTERVAL=1;BYMONTHDAY=19;BYMONTH=4
DTSTART;VALUE=DATE:20080419
X-MOZ-GENERATION:1
END:VEVENT
END:VCALENDAR

Import in a local calendar seems to work just fine.

Comment 3

[Bernard Desruisseaux]

When importing a recurring events with rescheduled instances defined in
separate components, all the separate components for these rescheduled
instances are ignored/lost.

Comment 4

[Bruno Browning]

Attachment: serialize entire item

Comment 5

[Daniel Boelzle [:dbo]]

Comment on attachment 317283 [details] [diff] [review]
serialize entire item

>+    getSerializedItem: function caldav_getSerializedItem(aItem) {
>+        var item = getIcsService().createIcalComponent("VCALENDAR");
>+        calSetProdidVersion(item);
>+        item.addSubcomponent(aItem.icalComponent);
>+        if (aItem.recurrenceInfo) {
>+            var exceptions = aItem.recurrenceInfo.getExceptionIds({});
>+            for each (var exc in exceptions) {
>+                item.addSubcomponent(aItem.recurrenceInfo.getExceptionFor(exc, true).icalComponent);
>+            }
>+        }
>+        return item.serializeToICS();

IMO you should use component "@mozilla.org/calendar/ics-serializer;1" (calIIcsSerializer) in here, which does the above for you.

apart from that, the patch looks good; r=dbo

Comment 6

[Bruno Browning]

Patch checked in (using ics-serializer) on HEAD and MOZILLA_1_8_BRANCH
->FIXED

Comment 7

[Andreas Treumann]

I checked this issue with http://andrew.triumf.ca/t0-weekly.moved1.5.ics and with a self created *.ics file (daily rule with one exception). I used a Bedework caldav server and also the RSCDS 0.80 qa-testserver (http://rscds.zathras.lss.wisc.edu/caldav.php/mozilla/home/). -> The issue isn't fixed, so I reopen this bug.

Comment 8

[Andreas Treumann]

I checked this with lightning build 2008081018.

Comment 9

[Bruno Browning]

Attachment: use getSerializedItem on adopt

this seems to fix the import problem. Note that the provided easter.ics file does not display properly after import, but that appears to be a views bug rather than a caldav provider bug: if you, for instance, change Easter from an allday/zerolength event to a one-hour one it will be displayed correctly on all the dates specified in the source easter.ics. Possibly caused by lack of DTEND in easter.ics, but at any rate a different bug.

Comment 10

[Daniel Boelzle [:dbo]]

(In reply to comment #9)
> the dates specified in the source easter.ics. Possibly caused by lack of DTEND
> in easter.ics, but at any rate a different bug.
maybae same issue as bug 445480?

Comment 11

[Daniel Boelzle [:dbo]]

Comment on attachment 333540 [details] [diff] [review]
use getSerializedItem on adopt

r=dbo

Comment 12

[Daniel Boelzle [:dbo]]

Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED again.

Comment 13

[Andreas Treumann]

Checked with lightning 2008081803 and sunbird 20080817 -> VERIFIED