Importing calendar event to different calendar re-emails all invitees

[espg]

I have multiple email accounts, so invariably someone will email me a calendar invite to different account then my primary calendar setup. Importing the ical event into a different calendar is easy enough, but there's an annoying quirk... when you import using gcalcli --calendar="[email protected]" import invite.cal to a different calendar than the original message recipient, the duplicated event lists you as the owner and resends the invitation out to the other calendar attendees. This creates spam-- other recipients will either accept the duplicate invitation and have two entries in their calendar, or will decline and clutter up my inbox with declined invitation messages.

How do you import a calendar event into a different calendar and not duplicate the invitation for other attendees?

[ferdinandyb]

I am also very much interested in this, because currently this makes import for me unusable :(

[jonjamesjr]

Another symptom of the same underlying issue: I added an event to my Google Calendar via gcalcli import, subsequently deleted it from my Google Calendar, and all the original invitees then received a message, apparently from me, telling them that the event was cancelled (which it was not). I'd love an option to not import any ORGANIZER or ATTENDEE information from the ical event.

[dbarnett]

@jonjamesjr that particular issue (where the event isn't moving calendars or anything but still churns deleting/recreating) might be fixed in #712, which switches from an "insert" operation to "import".

If anyone wants to test that version and see if it helps churn in any other cases that'd be super helpful.

There's also an explicit sendUpdates override that we could hook up if all else fails.

[dbarnett]

Alright yes, from my testing the "import" operation doesn't send invite emails. Maybe it's not ALWAYS ideal for it to skip invites, depending on your usage, but at least in this case it seems like it'll do what you want.

@jonjamesjr could you clarify the use case there? I think basically you want to import an event as a shadow copy, with all the same attributes except all attendee/organizer/contact information stripped?

[jonjamesjr]

That's right, @dbarnett. The motivation for the stipped-down version was basically to avoid accidentally notifying all the organizers and attendees if I subsequently delete the event from my Google Calendar. I caused a minor panic (happily quickly rectified) when in removing a duplicate entry from my Google Calendar I appeared to "cancel" a large formal evening event and to notify all the participants of this "fact"!

The attendee/organizer/contact information doesn't bother me by being stored in the event, so long as my interactions with the event don't trigger actions like contacting everyone listed.

I'm very grateful indeed for this fix, and would love to try it out, but unfortunately I'm struggling with my python installation on my Mac, which is stopping me from running gcalcli just at present. When I get enough minutes in a row I will try to fix that out and then test this.

[dbarnett]

Sure, sounds good!

So I think I get your use case for importing "stealth" events but I'm still thinking through if there's any good straightforward accommodation gcalcli can make for that. Just stripping off all the attendee info seems a little heavy-handed, and prompting you for whether to do that in the add flow would be a little cumbersome too. Did whatever way you deleted the event not prompt you for whether to send an email to attendees?

I absolutely agree it's frustrating when tools surprise you by sending emails on your behalf, and we should avoid that if there's a good low-impact way to avoid it.

[jonjamesjr]

I agree about stripping info being heavy-handed (it should just be information, after all, and potentially relevant information at that), and that a prompt would be cumbersome. But perhaps a flag on the command line (defaulting to no stripping)?

I don't think Google Calendar prompted me in any way that there would be emails sent when I deleted the event. If it had, I'm sure I would have said 'no way'!

[dbarnett]

Alright, then I'll recommend:

1. You file a ticket for a --strip-email-addrs arg or something like that
2. See if you can narrow down any repro for what cases may trigger unwanted emails like that, post any details you find there
3. I'll mark this issue fixed

Sound good?

[jonjamesjr]

Absolutely. And thanks!