Closed Bug 357399 Opened 18 years ago Closed 16 years ago

Import of iCalendar with (invalid?) RECURRENCE-ID is incomplete

Categories

(Calendar :: Import and Export, defect, P3)

Product:
Calendar
Component:
Import and Export
Version:
Sunbird 0.3
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sebo.moz, Assigned: dbo)

References

Details

I created an recurring event in Google Calendar and sent an invitation to myself.
Additionally Google sends me Reminders on every occurrence by mail. These reminders cannot be imported. Example:

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20061019T080000Z
DTEND:20061019T123000Z
DTSTAMP:20061019T074509Z
ORGANIZER;CN=***:MAILTO:***
UID:5e0s3er58bhokiune04mevh5b4@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=***;X-NUM-GUESTS=0:MAILTO:***
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=***;X-NUM-GUESTS=0:MAILTO:***
CLASS:PRIVATE
CREATED:20061017T211054Z
DESCRIPTION:This is to test the iMiP iTIP\nZeigen Sie Ihren Termin unter ht
 tp://www.google.com/calendar/event?action=VIEW&eid=NWUwczNlcjU4Ymhva2l1bmUw
 NG1ldmg1YjRfMjAwNjEwMTlUMDgwMDAwWiBzZWJhc3RpYW4uc2Nod2llZ2VyQGdvb2dsZW1haWw
 uY29t&tok=MzQjc2ViYXN0aWFuLnNjaHdpZWdlckBnb29nbGVtYWlsLmNvbWQxYjAwZmQzOWMzN
 TFjYTNhMzFiZjM5YWMwZDY2ZjdlZTk4ZDZjYWI&ctz=Europe%2FRome&hl=de an.
LAST-MODIFIED:19700101T000000Z
LOCATION:Bei mir zu Hause
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Testevent for Lightning
TRANSP:TRANSPARENT
RECURRENCE-ID:20061019T080000Z
END:VEVENT
END:VCALENDAR

Steps to reproduce:
1. Import example calendar

Result:
1. event is shown in agenda and in views
2. after refresh (changing the views) the event disappears from the views. It stays in agenda until restart.

Removing the RECURRENCE-ID solves the problem.
1. is RECURRENCE-ID invalid in this respect?
2. should RECURRENCE-ID be ignored if there is no RRULE
3. should there be an error message?
1. The Mozilla ICS parser assumes that RECURRENCE-ID is invalid in this context: it silently discards items that have RECURRENCE-ID but no parent item along about http://lxr.mozilla.org/seamonkey/source/calendar/base/src/calIcsParser.js#146
This makes sense to me, but I'm not finding anything in RFC2445 to support it.

2. I don't think we can just ignore RECURRENCE-ID here. I'm seeing this bug in a data feed from the (Oracle) calendar at my Uni: it's a URL with an embedded time-range specification, and GETting it provides iCalendar data from my calendar for the specified range. Under at least some cirucumstances, recurring events show up in this feed as separate VEVENTs with RECURRENCE-IDs -- but the same UID. Ignoring the RECURRENCE-ID while parsing such data would simply cause the parser to error on the duplicate UIDs.

3. I think an error message would be a good way to go here. Certainly just discarding items silently isn't good. It would also be possible to construct a valid, though dummy, parent item in the parser. This would at least get the imported data into Sb/Ltn. But in cases like the data feed from my Uni, Sb/Ltn would end up with a version of the recurrence set different from the one on the server, and - especially given that the ICS provider uses calIcsParser.js - I smell potential dataloss in that approach.

IMO we could go for a calICalendar::getItem(UID) and relate the incoming occurrence to that parent. I think that's intended here: the sender assumes that the parent is known.
The problem is that the user may have multiple calendars defined, so we need to look up all of them. Regarding CalDAV collections, (at least in theory) clashing UIDs may hit us in that case (although I doubt in practice); a UID needs only be uniquely scoped to its hosting collection, isn't it?
Finally, I am wondering why Google sends out iTIP REQUESTs with reminder mails at all; a plain eMail stating the alarm would IMO be equally sufficient and the event wouldn't be bloated with exception records. Sebo, does the sent out occurrence differ from its master event?

We should consider the following use case:
The user is not subscribed to his Google calendar. But he receives his Google mails. In this mails there would be the ics as described above. No parent item is known to calendar. I just retested and here is the master event (as written in the ICS feed by Google):

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20070619T203000
DTEND;TZID=Europe/Berlin:20070619T223000
RRULE:FREQ=DAILY;UNTIL=20070622;WKST=MO
DTSTAMP:20070619T174838Z
ORGANIZER;CN=***:MAILTO:***
UID:g66kf03tc8o0qe7umb7stfkjjg@google.com
CLASS:PRIVATE
CREATED:20070619T171138Z
DESCRIPTION:
LAST-MODIFIED:20070619T171139Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Testevent recurring
TRANSP:OPAQUE
END:VEVENT

and here the corresponding ics that is attached to the email:

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20070619T183000Z
DTEND:20070619T203000Z
DTSTAMP:20070619T173006Z
ORGANIZER;CN=***:MAILTO:*****
UID:g66kf03tc8o0qe7umb7stfkjjg@google.com
RECURRENCE-ID:20070619T183000Z
CLASS:PRIVATE
CREATED:20070619T171138Z
DESCRIPTION:Zeigen Sie Ihren Termin unter http://www.google.com/calendar/ev
 ent?action=*****&ctz=Europe%2FBerlin&hl=de an.
LAST-MODIFIED:19700101T000000Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Testevent recurring
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

So, as much as I can see, the occurence does not differ.
If the master event was known (event is already in the calendar), there would actually be no need to send this as an iTIP REQUEST. If, however, the event is not yet known, it sounds useful that the reminder that comes in by mail can be added to the calendar. We must be able to add this occurrence without knowing the parent item. 
The same problem exists when doing the same thing through zimbra.


I see the same problem when importing a file created from Sun iPlanet 5.1.1 csexport

(In reply to comment #1)
> discarding items silently isn't good. It would also be possible to construct a
> valid, though dummy, parent item in the parser. This would at least get the
> imported data into Sb/Ltn. But in cases like the data feed from my Uni, Sb/Ltn
> would end up with a version of the recurrence set different from the one on the
> server, and - especially given that the ICS provider uses calIcsParser.js - I
> smell potential dataloss in that approach.

Thinking about that approach, I like it. What's the problem? We are facing a set of dates belonging together, i.e. no rule; there are no generated proxy occurrences, but only "exceptional/overridden" items.
First look, I think we could safely generate a parent item, stuffing it with RDATEs of all those occurrences. That would at least satisfy our internal code, because I suspect a ton of code relies on having a parentItem for that.

(In reply to comment #6)
> 
> Thinking about that approach, I like it. What's the problem? We are facing a
> set of dates belonging together, i.e. no rule; there are no generated proxy
> occurrences, but only "exceptional/overridden" items.
> First look, I think we could safely generate a parent item, stuffing it with
> RDATEs of all those occurrences. That would at least satisfy our internal code,
> because I suspect a ton of code relies on having a parentItem for that.
> 

I think this approach would work well to solve the immediate problem of importing one of these parentless recurrences. Maybe I'm being hypercautious, but it seems to me that after doing this I have two different items in my calendaring space with the same UID, SEQUENCE, etc, but with different recurrence sets and no really good way to distinguish them. Sooner or later I'm going want to copy the item from one calendar store to another, sync, counter,  or otherwise do something that has the potential of overwriting the original, full copy of the item with the partial one -- unless I can distinguish them. I'm not sure that there's a good solution to this. Maybe the best we can do is something along the lines of an X-MOZ-TRUNCATED-RECURRENCE property applied to the constructed parent item so that it can be checked appropriately. 

Can this issue be targeted for 0.8?
Flags: wanted-calendar0.8?
Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.
Flags: wanted-calendar0.8? → wanted-calendar0.8-
IMO makes sense for 0.8, too; quite similar to bug 392465.
Flags: wanted-calendar0.8- → wanted-calendar0.8+
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Flags: tb-integration+
Flags: wanted-calendar0.8- → wanted-calendar1.0+
Assignee: nobody → daniel.boelzle
I've laid out the basics for a fix of this in bug 457203.
Depends on: 457203
Priority: -- → P3
Blocks: 345607
OS: Windows XP → All
Hardware: PC → All
Depends on: 392465
fixed with checkin of bug 392465
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Checked in nightly build 20081126 -> VERIFIED.
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.