Calendar invitation accept/decline buttons missing

[schiessle]

I just received a calender invitation and it seems like the accept/decline buttons are missing in the latest version (Nextcloud 19, Calendar 2.0.3):

[georgehrke]

@schiessle Wrong repo ;)

[georgehrke]

Not reproducible, please provide better reproduction steps

[schiessle]

I just checked the source code of the mail to make sure that it is not a rendering issue but also the source code doesn't contain the button.

Other invitations I received afterwards also had the buttons included.

@wobben how did you created the invitation? Have you done anything special? Can you provide the exact steps how you created the invitation?

[wobben]

@schiessle I created the appointment in the macOS Calendar app in my Sales calendar.
I just realized that I invited bjoern@nextcloud.com and not bjoern.schiessle@nextcloud.com.

Is this maybe the reason?

[schiessle]

@wobben just send another invitation, these time to the right email address with the same result. The buttons are again missing 😕 Seems to be at least reproducible on Matthias' account

[wobben]

I've sent the same invite now to georg.ehrke@nextcloud.com as well. You don't need to join this appointment ... ;-)

[georgehrke]

@wobben I got the invite and it also doesn't show any buttons for me. Will look into it.
Thx!

[frightener]

The buttons seem to be missing when using third-party apps (Thunderbird in my case). Creating an invite from the Nextcloud web UI worked as expected.

[georgehrke]

@frightener could you provide the intercepted HTTP request please?

[frightener]

Sorry, it seems like you can ignore my comment. In my case the invitation mail was just formatted differently by Thunderbird when the event was created within the same instance of Thunderbird.

[mrtumnus]

Here are the entries from nextcloud.log when Thunderbird creates the event:

{"reqId":"eNpNFd8IfTc1XU7f0Qpl","level":0,"time":"2021-05-24T17:08:16+00:00","remoteAddr":"x.x.x.x","user":"******","app":"core","method":"PUT","url":"/remote.php/dav/calendars/******/personal/77e9fedb-323d-4090-b619-c3fca5e00f2e.ics","message":"Sent mail to \"Array\n(\n    [******@example.com] => ****** ********\n)\n\" with subject \"Invitation: Test 1\"","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2","version":"20.0.9.1"}
{"reqId":"eNpNFd8IfTc1XU7f0Qpl","level":0,"time":"2021-05-24T17:08:16+00:00","remoteAddr":"x.x.x.x","user":"******","app":"core","method":"PUT","url":"/remote.php/dav/calendars/******/personal/77e9fedb-323d-4090-b619-c3fca5e00f2e.ics","message":"++ Starting Swift_SmtpTransport\n<< 220 mail.localdomain ESMTP Postfix (Debian/GNU)\r\n\n>> EHLO nextcloud.example.com\r\n\n<< 250-mail.localdomain\r\n250-PIPELINING\r\n250-SIZE 10240000\r\n250-VRFY\r\n250-ETRN\r\n250-STARTTLS\r\n250-ENHANCEDSTATUSCODES\r\n250-8BITMIME\r\n250-DSN\r\n250 CHUNKING\r\n\n++ Swift_SmtpTransport started\n>> MAIL FROM:<nextcloud@example.com>\r\n\n>> RCPT TO:<******@example.com>\r\n\n>> DATA\r\n\n<< 250 2.1.0 Ok\r\n\n<< 250 2.1.5 Ok\r\n\n<< 354 End data with <CR><LF>.<CR><LF>\r\n\n>> \r\n.\r\n\n<< 250 2.0.0 Ok: queued as 1C58A8E24\r\n","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2","version":"20.0.9.1"}
{"reqId":"eNpNFd8IfTc1XU7f0Qpl","level":1,"time":"2021-05-24T17:08:16+00:00","remoteAddr":"x.x.x.x","user":"******","app":"no app in context","method":"PUT","url":"/remote.php/dav/calendars/******/personal/77e9fedb-323d-4090-b619-c3fca5e00f2e.ics","message":"Deprecated event type for \\OCA\\DAV\\CalDAV\\CalDavBackend::createCalendarObject: Symfony\\Component\\EventDispatcher\\GenericEvent is used","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2","version":"20.0.9.1"}

Log entries when creating an event in Calendar web app are identical (except for user agent and ids, obv). Doesn't seem like I'm looking in the right place, as this is showing the email notification event rather than the actual POST/PUT of the event.

[mrtumnus]

Hacking around in the code and added some logging. The conditional in IMipPlugin.php here depends on getAttendeeRSVP(). For the web event case, this returns 1, but for Thunderbird it returns nothing (null?).

[mrtumnus]

Ok, I think I found it. Thunderbird does not set the RSVP field in the ATTENDEE property. Not sure what we can do about this... Perhaps this is an issue we could raise in Thunderbird or the TbSync extension (not sure where the event population happens).

Attendee field generated from Thunderbird:

ATTENDEE;CN=****** ********;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION:ma
 ilto:******@example.com

Attendee field generated from Calendar web app:

ATTENDEE;CN=****** ********;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=
 REQ-PARTICIPANT;RSVP=TRUE:mailto:******@example.com

EDIT: RSVP field checking was added in #12392.

[mrtumnus]

Looks like someone @ Mozilla is aware of this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1683636

[mrtumnus]

Aha! Setting a participant in Thunderbird to optional results in RSVP=TRUE, and buttons are displayed. Kinda goofy if you ask me (why do I care if optional participants are attending or not?!), but at least there's a workaround which allows the use Thunderbird for meeting invites.

[JMoVS]

On Mac OS Catalina, there seems to be the same issue. The buttons are there when during creation, participants are added. But if participants are added to an event that already exists, then no buttons appear.

Expected behaviour in my mind would be:

• if participant list changes and a new participant is added to an existing calendar entry, that participant should get an email with accept/Decline buttons
• if anything about the event changes, triggering a resend of that email, this email should individually per recipient contain accept/decline buttons (similar to how Google calendar does it - just always show those buttons!).
• bonus points for showing current attendee status in the email when anything of an event changes so people don't have to reconfirm

[ChristophWurst]

We'll have a look

[ChristophWurst]

Looks like someone @ Mozilla is aware of this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1683636

I'll have to reproduce myself but that looks promising.

On Mac OS Catalina, there seems to be the same issue. The buttons are there when during creation, participants are added. But if participants are added to an event that already exists, then no buttons appear.

Mind exporting the original ics for us for inspection? You can redact any sensitive infos.

[miaulalala]

Conclusion of internal discussion: remove the RSVP check on the email.

[JMoVS]

@ChristophWurst @miaulalala Is my input still needed or did you reproduce - not sure after

Conclusion of internal discussion: remove the RSVP check on the email.

;-)

[miaulalala]

@JMoVS I'm still glad of any input! Ideally we would do this RFC conform at a later date - but this likely depends on Thunderbird fixing their RSVPs :)

[JMoVS]

hmm, I don't really see how that is dependent on Thunderbird. When I add a participant in Apple Calendar, it will trigger a nextcloud invitiation email (with an attached ics), but without the accept/decline button. But that is completely independent from thunderbird.

[miaulalala]

Thunderbird is not sending an RSVP parameter, which we are currently checking for. See here: https://datatracker.ietf.org/doc/html/rfc5545#section-3.2.17

[JMoVS]

so should I open a new issue for Apple Mail and/or is Mail/Calendar just also not sending this RSVP parameter?

[miaulalala]

Ah yes, yours was an AppleMail issue. Hm, could you post the icals AppleMail is creating?

[miaulalala]

So I think it would be a good idea for this code

server/apps/dav/lib/CalDAV/Schedule/IMipPlugin.php

Line 258 in 9de329a

if (($method == self::METHOD_REQUEST) && $this->getAttendeeRSVP($attendee)) {

to look at the ROLE parameter too, not just RSVP. That would help in a lot of cases - any REQ-PARTICIPANT would need to send a reply and needs those buttons.

The RFC specifies for the ROLE:

If not specified on a property that allows this parameter, the default value is REQ-PARTICIPANT.

@JMoVS Apple Mail has the same issue as Thunderbird btw, see here: #11230, so this solution should help with your issues too.

[JMoVS]

very curious if this is gonna solve the issue (as I'm not sure that Apple Mail itself is strictly speaking involved when the Apple calendar app updates the server over CalDAV - I'll see what it looks like after the next auto update ;-)

[JMoVS]

thanks for the fix!