Update existing ICS with re-import?

[ajkessel]

The latest code will refuse to re-import an ICS where the UID for the event already exists in Google.

But what if the appointment info has changed -- is there a way to update the Google event based on the new information in the ICS?

I thought this was made possible with PR #712 but maybe I'm misunderstanding it.

Is there any elegant solution here short of using the legacy import switch?

One approach might be to use edit but I'm looking to script this, not have it execute interactively.

Note that if you've deleted the item via gcalcli, gcalcli still sees it as a duplicate and refuses to re-import.

[dbarnett]

Yup, I noticed this. See https://github.com/insanum/gcalcli/pull/712/files#r1731770966.

IMO it should prompt for whether to update existing event after "import" reports it as a duplicate (probably invoking "insert" in that case, or maybe trying to do more of a "patch" on the existing event), and then respect a flag like --no-interactive to make it just warn and skip or something like that.

[ajkessel]

In the meantime, what is the best workaround? I guess you could delete the event and then re-import with legacy-import? Is there something else that makes more sense?

[dbarnett]

IDK if there's a great workaround for your case besides waiting for a new version. =/

If it were me in a pinch, I'd probably try to fork the ics file to split out the problematic VEVENT objects into their own file and then import --use-legacy-import that one. That might actually be another nice layer of fallback to have in gcalcli too, to always dump a tmp ics file with any events it skipped importing so you can conveniently retry after any failure scenario.

[dbarnett]

Few updates here as I'm getting closer to a 4.5 release milestone:

1. Any failed imports will now get dumped to a rej.ics file in tmp so if you just want to insert them all instead, you'll be able to conveniently do that with a command like gcalcli import --use-legacy-import /tmp/gcalcli.d3adb33f/rej.ics.
2. The behavior of updating existing events is still weird and I haven't tracked down the exact issues yet, but I suspect it's a straight-up bug in the Calendar API. They accept a sequence number but don't seem to take it into account at all for import.
3. I'm having second thoughts about having import be just the new default, considering it has so many behavior quirks and in the API docs they say it's used to add a private copy of an existing event to a calendar. May be too late to completely reverse course, but I might make some tweaks to make it rely more on insert in the future where possible.

I probably won't stall the 4.5 release on figuring out The Whole Story for 2 and 3, but 1 is done now and that'll give us nice trivial workaround in the 4.5 release.

[dbarnett]

K, forking off the more nuanced parts of this fix into #784 and marking this part as Fixed. It's now possible to re-import to update events but manual and clunky.