Right, this one seems like a core architectural issue. I am trying to throw in some data from an Office 365 iCal feed and noticed that every time I did an import the events got duplicated. On the Feeds mapper I have a unique relation specified for GUID and UID so I thought I would check the source iCal for any funnies happening to UID. Hey presto, or so I thought at the time, on each import the feed would spit out the same data but with changed UIDs. Right, I thought, let me share this problem with our friends at Microsoft but just before that I checked out the iCalendar spec to make sure of my facts. Shouldn't have done that because it shattered the base on which I had built my limited iCalendar knowledge, that is, I had a core assumption that a UID value would be unique for every event item but not so. My understanding now is that the iCal can have multiple event items with THE SAME UID and to differentiate the records you need to look further at other properties (SEQUENCE and RECURRENCE-ID I think). From RFC 5545 it seems for recurring events the UID contains a common value for the entire recurring set.

So to summarise, and maybe these should be split into two Date iCal issues, we have:

1. The same iCalendar event can have different UIDs.

2. Different iCalendar events can have the same UID (think this is only limited to recurring events).

Comments

mjkovacevich created an issue. See original summary.

coredumperror’s picture

coredumperror CreditAttribution: coredumperror commented

See section 4.8.4.7 of RFC 5545 for details on why Date iCal is designed the way it is. I've never once seen an iCal feed that uses the SEQUENCE and RECURRENCE-ID attributes, since RRULE is the usual method for describing recurring events. Date iCal supports RRULE, but I guess it doesn't support SEQUENCE and RECURRENCE-ID. I have no intention of adding support for such, mostly because Date iCal is in maintenance-only mode since my code shop is in the process of dropping Drupal altogether.

As for the UID for the same event being different from one retrieval of an Office 365 iCal feed to another, that's legal under the spec, but most calendar servers don't do that because it leads to the exact problem you're having. Leave it to Microsoft to forget that more-than-somewhat-important detail when they implemented iCal export in Office 365. They are a frequent thorn in my side when dealing with iCal imports.

I'm afraid there's nothing Date iCal's import code can do about the inconsistent UIDs that Office spits out. You might be able to set up a different uniqueness identifier, though. Title + Date would probably be sufficient.

coredumperror’s picture

coredumperror CreditAttribution: coredumperror commented
Status: Active » Closed (works as designed)
mjkovacevich’s picture

mjkovacevich CreditAttribution: mjkovacevich as a volunteer commented

Agree with you on the scarcity of seeing SEQUENCE and RECURRENCE-ID properties in general use with events with the same UID. After a few long tedious web searches it seems that this scenario pops up if a singular occurence of a recurring event is changed in the calendar app, for example, an event is scheduled for every Monday at 10am but for a particular Monday the event is moved to 2pm. The iCal file would then have a VEVENT item for the recurring 10am events as normal, with RRULE, and a separate one for the 2pm event, with UID the same as the recurring event and RECURRENCE-ID added. Why the spec doesn't just allow for some GROUP-ID property and keep the UID unique I have absolutely NO idea. Seems to break any sort of referential integrity logic by allowing the UID to be duplicated, but hey its there and we have to live with it, warts and all.

On your suggestion to use another uniqueness criteria I looked into trying to do this with Feeds but the mapper doesn't seem to allow me to use the date for this. It only seems to have uniqueness options for UID and Title/Summary properties. I am also not sure whether it will allow multiple sources for uniqueness???

After some thinking I am now considering two options:

1. Date iCal hooks to alter the VEVENT UID, in other words, get the VEVENT data and check whether an event already exists in my table (based on various criteria, currently proposing start date, title and creation date). If it exists get the UID and replace the one coming in from the feed.

2. Presave hook on my Event node. Similar to above.

Any recommendations from your side on which method sounds more Drupalish or technically superior?

By the way, thanks for the great work you have done and are continuing to do in the Drupal iCalendar space. Every one of our clients request calendar integration when first discussing a project with them. I almost feel like this stuff should be supported in Core going forward as it is such a base requirement.

P.S. Sorry to hear about your employer dropping Drupal, and just at a time when things are getting really exciting with D8 and Symfony.

coredumperror’s picture

coredumperror CreditAttribution: coredumperror commented

I think your idea of using Date iCal's hooks is probably your best bet. hook_date_ical_import_component_alter() or hook_date_ical_import_post_parse_alter() will probably work for this purpose.

Thanks for the compliment! I've definitely put a lot of time, effort, and frustration into my two Drupal modules, so I am somewhat sad to be abandoning them. But Drupal just doesn't work as well for our company's needs as we expected, and we're moving to an alternate platform in the not-to-distant future.