Import: check if UID already exists, check which one is newest and update if necessary.

[georgehrke]

• Before importing, send request with all UIDs to the server. (or maybe not all but 50 at a time)
• If it doesn't give a 404, parse the calendar-data from the server and compare the LAST-MODIFIED and SEQUENCE-properties of both.
• If the version, the user wishes to import, is newer, update the event on the server.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[tcitworld]

I'm guessing you mean when importing data in an existing calendar, it makes little sense when creating a new one (UIDs are only unique in their calendar - even though there should be globally unique).

[georgehrke]

Yes, only for existing calendars.
Although it would be nice to check for the UID globally, but that's something for way later.

[r2evans]

(Is this why I've been beating my head against a wall trying to update events via import?)

The iCal spec (ref 5545) says that event updates should occur based on UID and SEQUENCE (and/or based on DTSTAMP and/or LAST-MODIFIED). If we're doing an import, shouldn't one or more of those fields be referenced?

It's a common enough use-case (I believe) for a user to upload an updated (externally-provided) .ics file and expect that updated VEVENTs are correct in the calendar app.

(I think my only workaround at the moment is to either delete all updated events and reimport them, ignoring all import failures. Sadly, this means I need to know which have been changed. Lacking that, I often end up deleting all events in that category and time-span and re-importing everything. It works well enough and all other users of that calendar eventually get what they need, I think ... but it defies the RFC/spec, and I'm not 100% certain that some client won't out-smart this somehow, such as based on UID.)