Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling calendar invitations and responses using email #2149

Closed
yanosz opened this issue Nov 16, 2016 · 4 comments
Closed

Handling calendar invitations and responses using email #2149

yanosz opened this issue Nov 16, 2016 · 4 comments
Labels
1. to develop Accepted and waiting to be taken care of enhancement feature: dav

Comments

@yanosz
Copy link

yanosz commented Nov 16, 2016

Refs:

From what I got, I can add participants to an event and they are invited by mail.
But: When I respond using the MUA, the response is sent to the authors private mailbox. Nextcloud doesn't get the status.

That's bad, since I need nextcloud to reflect the participant status of an event, even if no MUA updating the event using CalDav is present. This should happen without further processing at the site sending the invitation (Eg. logging in into nextcloud or acknowledging the response in nextcloud): In case of shared calendars, the participants status should be updated at once.

@MariusBluem MariusBluem added 1. to develop Accepted and waiting to be taken care of enhancement feature: dav labels Nov 16, 2016
@yanosz
Copy link
Author

yanosz commented Nov 16, 2016

Thinking about an implemenation, I've no idea on how clients handle https / http addresses in CAL-ADDRESS value types for deeplinks (aka jumping into nextcloud).

Refering to RFC 2445 any uri is allowed... http://www.kanzaki.com/docs/ical/calAddress.html .. but most clients may focus on mail.

If a deeplink doesn't work, nextcloud may need to subscribe to imap. Although imap is a very interesting sharing / groupware protocol - imho it's out of scope to have a general imap-backend.

Another idea is to have a mail server piping incoming emails to an adapter-script, posting the email's content .. but this may be nasty from an operations point of view.

@MorrisJobke
Copy link
Member

Duplicate of #2338

@mchobbel
Copy link

mchobbel commented Aug 4, 2021

It's good to see the buttons in the email-body are working nicely. Still, from a usability perspective, it is a big wish to see the email-route working as well.

The problem is

  1. Most email-clients will present multiple sets of (Accept / Maybe / No) buttons. Some buttons work, others don't.
  2. Users are presented with various invitation emails from various origins (outlook, google, etc), and at this point the user must be very careful of which buttons to use for each particular origin.

Are there any plans to do such server based processing of incoming emails?

@colans
Copy link

colans commented Mar 10, 2022

@mchobbel I believe that's #19144. Please hit the 👍 button over there to show your support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of enhancement feature: dav
Projects
None yet
Development

No branches or pull requests

5 participants