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:email@example.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:firstname.lastname@example.org 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:email@example.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?
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: wanted-calendar0.8- → wanted-calendar1.0+
fixed with checkin of bug 392465
Status: NEW → RESOLVED
Last Resolved: 10 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.