No mail invitation send for new appointment on CalDav sync

[jokakilla]

### Steps to reproduce 1. Create a new appointment with an external participant on your smartphone 2. Sync the calendar using CalDav with your owncloud ### Expected behaviour Owncloud should sent an invitation to all participants like it does if an appointment was created using the Owncloud Webinterface. ### Actual behaviour Owncloud does not sent an email even though the caldav sync was successful and the new appointment is visible at the Owncloud webinterface. After selecting the appointment at the webinterface it even shows the participant. ### Server configuration **Operating system**: CentOS Linux release 7.2.1511 (Core) **Web server:** Apache 2.4.6 **Database:** Maria DB 5.5.44 **PHP version:** PHP 7.0.4 **ownCloud version:** (see ownCloud admin page) Owncloud 9.0.0 **Updated from an older ownCloud or fresh install:** 8.0, 8.1, 8.2 **Where did you install ownCloud from:** http://download.owncloud.org/download/repositories/stable/CentOS_7 **Signing status (ownCloud 9.0 and above):** ?? ``` Integrity Check: Only two additional php scripts added by me. No changes on the owncloud code base. Results ======= - core - EXTRA_FILE - dyndns/update.php - adminer/index.php ``` **List of activated apps:** ``` Enabled: - activity: 2.2.1 - calendar: 1.0 - comments: 0.2 - contacts: 1.1.0.0 - dav: 0.1.5 - federatedfilesharing: 0.1.0 - federation: 0.0.4 - files: 1.4.4 - files_pdfviewer: 0.8 - files_sharing: 0.9.1 - files_texteditor: 2.1 - files_trashbin: 0.8.0 - files_versions: 1.2.0 - files_videoplayer: 0.9.8 - firstrunwizard: 1.1 - gallery: 14.5.0 - notifications: 0.2.3 - provisioning_api: 0.4.1 - systemtags: 0.2 - templateeditor: 0.1 - updatenotification: 0.1.0 Disabled: - encryption - external - files_external - user_external - user_ldap ``` **The content of config/config.php:** ``` { "system": { "instanceid": "ocuu9enp4kko", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "private_ip", "public_domain", "private_hostname" ], "datadirectory": "\/var\/ownclouddata", "memcache.local": "\\OC\\Memcache\\APCu", "overwrite.cli.url": "http:\/\/private_ip\/owncloud", "dbtype": "mysql", "version": "9.0.0.19", "dbname": "owncloud", "dbhost": "localhost", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "logtimezone": "UTC", "installed": true, "mail_smtpmode": "smtp", "mail_smtphost": "myprovider.com", "mail_smtpsecure": "tls", "mail_smtpport": "587", "mail_smtpauth": 1, "mail_smtpauthtype": "LOGIN", "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "mail_from_address": "givenname.lastname", "mail_domain": "myprovider.com", "maintenance": false, "theme": "", "loglevel": 2, "updatechecker": false, "trashbin_retention_obligation": "auto" } } ``` **Are you using external storage, if yes which one:** No **Are you using encryption:** no **Are you using an external user-backend, if yes which one:** No ### Client configuration **Browser:** Not applicable. Calendar Client "Business Calendar 1.4.8.5". CalDav Client "CalendarSync 13.44". **Operating system:** Android 4.4 ### Logs #### Web server error log ``` private_ip - joka [27/Mar/2016:14:59:56 +0200] "OPTIONS /owncloud/remote.php/caldav/calendars/joka/owncloudpers%c3%b6nlich/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" private_ip - joka [27/Mar/2016:14:59:56 +0200] "REPORT /owncloud/remote.php/caldav/calendars/joka/owncloudpers%c3%b6nlich/ HTTP/1.1" 207 174271 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" private_ip - joka [27/Mar/2016:14:59:57 +0200] "REPORT /owncloud/remote.php/caldav/calendars/joka/owncloudpers%c3%b6nlich/ HTTP/1.1" 207 4441 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" private_ip - joka [27/Mar/2016:14:59:59 +0200] "PROPFIND /owncloud/remote.php/caldav/calendars/joka/owncloudpers%c3%b6nlich/ HTTP/1.1" 207 455 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" private_ip - joka [27/Mar/2016:14:59:59 +0200] "OPTIONS /owncloud/remote.php/caldav/calendars/joka/owncloudgeburtstage/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" private_ip - joka [27/Mar/2016:15:00:00 +0200] "REPORT /owncloud/remote.php/caldav/calendars/joka/owncloudgeburtstage/ HTTP/1.1" 207 18711 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" private_ip - joka [27/Mar/2016:15:00:00 +0200] "PROPFIND /owncloud/remote.php/caldav/calendars/joka/owncloudgeburtstage/ HTTP/1.1" 207 450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20120101 Firefox/29.0 like (Lightning/1.0b2 Thunderbird/3.1.13)" ``` #### ownCloud log (data/owncloud.log) ``` Even on loglevel 0 nothing is printed out during caldav sync. ```

[PVince81]

@DeepDiver1975 enhancement ? Or regression ? Not sure if the calendar app ever sent any invitations ?

[DeepDiver1975]

afaik we did not send invitations in the past - in addition we explicitly tested this feature for 9.0 -> most probably a setup issue

[jokakilla]

Hi, as far as I remember, email invitations have not been sent in earlier releases. So i was very happy to receive an email with an ics file attached after creating an appointment with the calendar app. Of course it is possible that the reason for the issue is a misconfiguration. The information that this is an usecase that should be working is great. If so it would be nice to get a hint where to start with further investigations.

Thanks

[RobinMcCorkell]

It's typically the calendar client's responsibility to send the email, so when you created the event on your Android device it should have the option to send an email.

[jokakilla]

Thanks...It's possible to share the appointment with K9-Mail which then creates an email with an ICS attachment.

[LubosKolouch]

That is way too complicated for a "normal user" having to forward the invite. With other groupware solutions you simply create the meeting, put invites there and... done. For me this is a major showstopper... I cannot imagine going to the non-IT users and asking them to create meeting, open email client, forward.

[DeepDiver1975]

The caldav Backend is sending invitations. They are not send if the calendar is shared or if the Email of the Organizer does not match with the users Email address.

[brianjmurrell]

I can confirm @jokakilla's experience with 9.0.2. Meetings created in the OC calendar app send meeting invitation e-mails. Meetings created with, say, Evolution don't. Exact same meeting recipient.

About this though:

They are not send if the calendar is shared

Why should the sharing status of the calendar matter? Just because I share my calendar with my assistant doesn't mean that external users that I invite to meetings should not get their invitation. Is this also the case for the OC calendar app? IOW, if the OC calendar app sends an e-mail invitation should the caldav backend also send e-mail invitations for the same users/recipients?

or if the Email of the Organizer does not match with the users Email address.

What does this mean exactly? Which two things here are being compared exactly?

Is "users Email address" here the e-mail address in the profile of the OC user?

How is the "Email of the Organizer" determined? Is it in the caldav request? How can we examine what that value was set to see if this not matching is why caldav meetings are not resulting in e-mail invitations?

I'm fairly sure these would be matching in my case, but as I said, external meeting invitees are not getting e-mail invitations from caldav meeting requests.

That all said, I am almost giddy at the though that this is all working now. Just seems to be an issue with caldav requests. The plumbing to send the invitations is clearly all there and working.

[DeepDiver1975]

Scheduling doesn't work on calendars which have been shared with a user. For the owner of the calendar is will always work.

The event organizer is an ical entry of the event. It is set by the client (evolution etc) and if this one matches up with the email of the owner invitations will be send.

Hope this explains the process.

[brianjmurrell]

Scheduling doesn't work on calendars which have been shared with a user. For the owner of the calendar is will always work.

To clarify, scheduling won't work when somebody other than the owner adds something to a shared calendar but does still work if the owner adds something to shared calendar?

The event organizer is an ical entry of the event. It is set by the client (evolution etc) and if this one matches up with the email of the owner invitations will be send.

So in my case, I am fairly sure that those are matching but I am still not seeing OC send event e-mails from meetings I schedule in Evolution. So this seems like it is in fact a bug.

[Ozzie76]

Same issues here. Invites are received (thus sent ok) when using the Owncloud web interface. On android, using the Google calendar app, scheduling an event and inviting a user in a different domain. When using a calendar hosted on: 1) the Google Calendar service: an invite is received by the invitee. 2) the Outlook.com Calendar service: an invite is received by the invitee. 3) the Owncloud Calendar service (9.0.3): NO invite is received by the invitee. This used to work flawlessly. I noticed it not working a week ago, but don't know when it started exactly. Fine if this is a configuration issue, but how to troubleshoot?

[DeepDiver1975]

I just tested this with dmfs caldav sync. The organizer field holds not the mail address of the user but some looks more like username@servername - no idea how this can be configured.

@dmfs any idea?

[DeepDiver1975]

And with evolution the organizer property is not filled :cry:

[brianjmurrell]

So this trying to match the organizer field of the event to the e-mail account of the OC user doesn't seem to be too reliable of a heuristic. :-(

Is it really necessary? What is the purpose?

Where in the code is it so that I can try disabling it to see if this is my problem.

[DeepDiver1975]

So this trying to match the organizer field of the event to the e-mail account of the OC user doesn't seem to be too reliable of a heuristic. :-(

Is it really necessary? What is the purpose?

You need to have an identifier to know if the one who is currently editing the event is the organizer. The organizer field is an email address which is mapped within the caldav implementation.

This is all part of the caldav specs.

Where in the code is it so that I can try disabling it to see if this is my problem.

Disabling this check will not help because all of a sudden updates will be sent out for events where you are not the organizer but only a participant.

[DeepDiver1975]

maybe @evert can bring some additional light into this - thx

[brianjmurrell]

Disabling this check will not help because all of a sudden updates will be sent out for events where you are not the organizer but only a participant.

I'm not sure that is worse than the current situation where nobody is getting any updates for any events modified by anyone.

Can you humour me and tell me where in the code this check is so that I can decide for myself which is the worser behaviour?

[DeepDiver1975]

Can you humour me and tell me where in the code this check is so that I can decide for myself which is the worser behaviour?

that is deep in the sabre dav library ... give me a sec ...

[brianjmurrell]

If the caldav specs require the organizer to be an e-mail address and in a given caldav request it is not, that would be worth logging I think so that people understand why they are not getting updates and can go bug their client implementer to fix their client.

[DeepDiver1975]

that is deep in the sabre dav library ... give me a sec ...

the whole logic is in https://github.com/owncloud/3rdparty/blob/master/sabre/vobject/lib/ITip/Broker.php

[DeepDiver1975]

If the caldav specs require the organizer to be an e-mail address and in a given caldav request it is not,

You simply don't know that.

An event is pushed to your calendar where the organizer is chuck@norr.is - you are not chuck norris so most probably you are not the organizer. All find. Maybe you are in the list of attendees - but even if not: find as well

[brianjmurrell]

An event is pushed to your calendar where the organizer is chuck@norr.is - you are not chuck norris so most probably you are not the organizer. All find. Maybe you are in the list of attendees - but even if not: find as well

But you also said:

And with evolution the organizer property is not filled 

So that is clearly a violation of the spec, yes? If so, it's loggable then, right?

[DeepDiver1975]

So that is clearly a violation of the spec, yes? If so, it's loggable then, right?

it's quite legitimate to have no organizer - it doesn't make sense to have attendees then for sure.

[brianjmurrell]

So what other options are there for finding broken clients?

I'm more than happy to go harass client implementers but I need to have evidence to do that.

[LubosKolouch]

also, it puts end-users into difficult situation if (in theory) their client devs refuse to do anything with that, and OC/NC does nothing as well...

They have no control of either...

Lubos

[DeepDiver1975]

So what other options are there for finding broken clients?

Test with every client out there and open bug reports with the clients.

In addition is is worth to start some documentation efforts in our docs to document the various clients and see how they might be capable of making this work.

[brianjmurrell]

Test with every client out there and open bug reports with the clients.

That doesn't prove that the client is broken, and how it's broken. The client implementer could just as easily point the finger back at OC and say it's broken since there is no evidence to present that the client is the problem.

[DeepDiver1975]

Form my understanding pointing fingers is not the way we want work.

[evert]

Hi!

Few things I take from this thread, not sure if I'm hitting home:

1. ORGANIZER is required for scheduling
2. To figure out if we need to do any scheduling, we match the current users' email address (or principal uri) with either ORGANIZER or one of the ATTENDEES.
3. In iCalendar, ATTENDEE without ORGANIZER is afaik meaningless and possibly invalid iCalendar.
4. If those points don't really provide a hint to what might be wrong, share the iCalendar object that is generated and should emit invitations.

[LubosKolouch]

can the organizer be some kind of no-reply address?

Lubos

On Thu, Jul 07, 2016, 07:02:28, Evert Pot wrote:

Hi!

Few things I take from this thread, not sure if I'm hitting home:

1. ORGANIZER is required for scheduling
2. To figure out if we need to do any scheduling, we match the current users' email address (or principal uri) with either ORGANIZER or one of the ATTENDEES.
3. In iCalendar, ATTENDEE without ORGANIZER is afaik meaningless and possibly invalid iCalendar.
4. If those points don't really provide a hint to what might be wrong, share the iCalendar object that is generated and should emit invitations.

---

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/owncloud/core/issues/23600#issuecomment-231086578

[evert]

Yes but it needs to match the current users' address specified in the system

[evert]

Just so you understand, the entire system hinges on the fact that we can figure out your role in the scheduling process. We can only figure out your role and the action you are taking by finding out who you are, and the uri / email address is used to do that.

To give you a straightforward example of why this is important: if you DELETE an iCalendar event, this will result in a PARTSTAT=DECLINED if you are an attendee, and the entire event gets METHOD:CANCEL if you were the organizer. This is just one minor example, but take it from me that the entire system was designed based on having this bit of information.

Part of the reason for this is that a client doesn't just sent a small api call to the server saying 'cancel this event please', but it only updates the entire iCalendar event, so the only thing we can do is compare the old iCalendar object with the new iCalendar object, and figure out what the intended change was.

Anyway, if you are saying that evolution does not set the ORGANIZER this would be quite surprising as I believe that evolution's iTip system is actually quite complete. Is it possible that you simply did not correctly set up your own email address when you added the calendars? I'm fairly certain that in Evolution's CalDAV setup procedure you have to set "your own" email address, and if that doesn't match whatever owncloud has stored, this will basically just fail.

[DeepDiver1975]

Anyway, if you are saying that evolution does not set the ORGANIZER this would be quite surprising as I believe that evolution's iTip system is actually quite complete. Is it possible that you simply did not correctly set up your own email address when you added the calendars? I'm fairly certain that in Evolution's CalDAV setup procedure you have to set "your own" email address, and if that doesn't match whatever owncloud has stored, this will basically just fail.

I guess this is more an issue with Gnome Online Accounts which sets up the caldav account within evolution based on the ownCloud account. There is no setting for the email address to be used.

left: regular caldav settings right: GOA settings

[brianjmurrell]

So, I created an event in one of my OC calendars in Evolution and added an attendee. The attendee didn't get an e-mail.

I exported the event and the .ics file says:

ORGANIZER;CN=Brian J. Murrell:MAILTO:brian@example.com

That is my correct e-mail address.

Is it possible that you simply did not correctly set up your own email address when you added the calendars?

Is this in reference to adding them to OC or adding them to Evolution?

Surely the ORGANIZER field above is confirming that Evolution is using the correct address, yes? That is the address that matches the Email field in https://owncloud.example.com/index.php/settings/personal.

Are these the two that are being compared?

[brianjmurrell]

FWIW: I used GOA to add my account to Evolution.

[DeepDiver1975]

Are these the two that are being compared?

yes - maybe there is an issue in processing the ORGANIZER property in ics.

Let me test this.

[evert]

If @DeepDiver1975 says that it's correct then I feel that this might be an owncloud bug, not an evolution one.

[DeepDiver1975]

Organizer is sent from evolution for non-goa calendars for me - invites are sent. hmmmm ....

We need to debug this further

[DeepDiver1975]

@brianjmurrell can you please setup the calendar in evolution directyl without GOA and retry? THX

[brianjmurrell]

@DeepDiver1975 So yeah, a caldav calendar directly in Evolution works. But in the .ics exported from the OC calendar client, the ORGANIZER property is identical to the event created in the GOA calendar. Apart from the various different timestamps of the two events I created, the only other difference is in the ATTENDEE property.

In the GOA calendar created event the property is:

ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;CN=brian@example.ca;LANGUAGE=en:MAILTO:
 brian@example.ca

and in the caldav created one it's:

ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=brian@example.ca;LANGUAGE=en;SCHEDULE-STATUS=1.1:MAILTO:bria
 n@example.ca

The odd wrapping in the second one is verbatim as it is in the .ics export.

[brianjmurrell]

Organizer is sent from evolution for non-goa calendars for me - invites are sent. hmmmm ....

But if we are to believe the .ics that OC exports, the organizer is sent from Evolution for GOA calendars also. Very strange.

[DeepDiver1975]

okay - I'll debug this further tomorrow - but it looks to be GOA specific.

[dmfs]

@DeepDiver1975 CalDAV-Sync currently puts whatever you enter as the account name into the ORGANIZER field. The account name field, however, is pre-populated with one of the the calendar-user-addresses found on the server. If the server doesn't return any calendar-user-address that has a mailto: scheme we fall back to the server name. We'll change that behavior in future releases, so we'll always use the calendar-user-address as the ORGANIZER if we find one.

[DeepDiver1975]

Thanks a lot @dmfs

[brianjmurrell]

Confirming @dmfs, I reconfigured my CalDAV-Sync adaptor and changed my account name from "Home" to my e-mail address, and indeed, I now get invitations when scheduling on an OC calendar from Android.

It even says right in the configuration that the account name is used as the organizer address.

But it would be good to separate those for people who want to use a non-e-mail account name.

[brianjmurrell]

@DeepDiver1975 said:

okay - I'll debug this further tomorrow - but it looks to be GOA specific.

Did you get a chance to make any headway with this by chance?

[DeepDiver1975]

Not yet 😭

[orobin]

I have the same problem with both Caldav-Sync and DAVdroid on android. I tried the solution proposed by brianjmurrell and could not make it work. Is it just use your account email as account name?

[brianjmurrell]

I wonder if there has been any progress on the GOA account flavour of this problem yet?

[allgood]

Well, tested here, with DAVDroid and Gnome Online Accounts... no way to send invitations by the server. Checked the account name on DAVDroid, it is correctly assigned to the same email address of the account on the server. If using Evolution without GOA, with the toggle telling that server handles the meeting invitations, messages are delivered quickly!

I tried to look at the code in order to make a quick hack, but I couldn't find where the server decides that meetings coming from GOA and Android don't deserve to get the mail service from it. Any ideas where I could look at?