import should automatically update existing events based on UID/SEQUENCE values

[dbarnett]

Right now if you import an ics file with an updated version of an event already on your target calendar, it will fail to import saying the event is a duplicate. Instead it should update the existing event (since UID indicates it's the same logical event and SEQUENCE indicates the version being imported is newer). See #730 for additional context.

There's already a workaround to do this manually but the process is clunky (by feeding the dumped rej.ics file back through import --use-legacy-import).

Note versions prior to #712 / 4.4.0 didn't have this issue, but had the inverse issue of updates being too aggressive and tending to generate duplicate events and notification spam.

[dbarnett]

On a technical level, this is happening because for some bizarre reason Google's import method that we switched to accepts a sequence number but doesn't do anything with it and instead just blows up saying events with the same UID are "duplicates".

It seems like we need more logic to sometimes use import and sometimes insert and I don't see any obvious way to detect which one without calling multiple methods on the same event.

[michaelmhoffman]

I believe reimporting ICS events using the Google Calendar web interface changes nothing if the UID is the same and the event still exists.

I have some code that generates ICS files and I set the UID to sha256("\0".join([dtstart, dtend, location, summary, description]).encode("utf-8")).hexdigest() to always have unique UIDs for any changes to the major fields, which avoids this issue.

[dbarnett]

Hmm, then it might be good to stick close to their existing behavior, but in the context of gcalcli the "duplicate" behavior surprised me at first. I was testing gcalcli import by trying to reimport an event I'd previously imported and deleted, and didn't understand at first why the import had no effect (because the event still "existed" but only as a deleted event).

Either way we could try to make the behavior pretty self-explanatory in the command output, and consider supporting a way to force it when needed.