No mail invitation send for new appointment on CalDav sync #23600

Open
jokakilla opened this Issue Mar 27, 2016 · 67 comments

Projects

None yet
@jokakilla
jokakilla commented Mar 27, 2016 edited

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
Collaborator

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

@DeepDiver1975
Member

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

@Xenopathic
Member

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.

@kolcon
kolcon commented Jul 3, 2016

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
Member

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
brianjmurrell commented Jul 3, 2016 edited

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.

@brianjmurrell brianjmurrell referenced this issue in owncloud/calendar Jul 3, 2016
Closed

e-mail notification of meeting invitation #603

@DeepDiver1975
Member

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
Ozzie76 commented Jul 6, 2016

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
Member

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
Member

And with evolution the organizer property is not filled 😢

@brianjmurrell
brianjmurrell commented Jul 7, 2016 edited

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
Member

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
Member

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
Member

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
Member

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
Member

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
Member

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
brianjmurrell commented Jul 7, 2016 edited

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.

@kolcon
kolcon commented Jul 7, 2016
@DeepDiver1975
Member

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
Member

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

@evert
evert commented Jul 7, 2016

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.
@kolcon
kolcon commented Jul 7, 2016

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:
#23600 (comment)

@evert
evert commented Jul 7, 2016

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

@evert
evert commented Jul 7, 2016

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
Member

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
bildschirmfoto von 2016-07-07 16-49-12

@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
Member

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
evert commented Jul 7, 2016

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

@DeepDiver1975
Member

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

We need to debug this further

@DeepDiver1975 DeepDiver1975 added this to the 9.2 milestone Jul 7, 2016
@DeepDiver1975
Member

@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
Member

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

@dmfs
dmfs commented Jul 8, 2016

@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
Member

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
Member

Not yet 😭

@orobin
orobin commented Aug 18, 2016

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?

@ctodobom
Contributor

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?

@DeepDiver1975
Member

Any ideas where I could look at?

the relevant information is stored in the organizer field within the event.
As far as my research and debugging goes GOA is not setting the proper email address in the organizer field. No idea about davdroid.

@ctodobom
Contributor

the relevant information is stored in the organizer field within the event.
As far as my research and debugging goes GOA is not setting the proper email address in the organizer field. No idea about davdroid.

Looking at the ICS file downloaded from owncloud, organizer looks correct, with ORGANIZER;CN:My Name:MAILTO:my@email

any point on owncloud code where I can intercept the ics file right after it comes from the client app?

@ctodobom
Contributor

@DeepDiver1975 , I've fixed this on nextcloud 10 with the following changes:

--- nextcloud/apps/dav/appinfo/v1/caldav.php    2016-08-25 03:59:50.000000000 -0300
+++ nextcloud-imip/apps/dav/appinfo/v1/caldav.php   2016-09-21 14:23:36.251450162 -0300
@@ -78,6 +78,8 @@
 }

 $server->addPlugin(new \Sabre\CalDAV\ICSExportPlugin());
+$server->addPlugin(new \Sabre\CalDAV\Schedule\Plugin());
+$server->addPlugin(new OCA\DAV\CalDAV\Schedule\IMipPlugin( \OC::$server->getMailer(), \OC::$server->getLogger()));
 $server->addPlugin(new ExceptionLoggerPlugin('caldav', \OC::$server->getLogger()));

 // And off we go!

When running from web page, this code is never executed, and apps/dav/appinfo/v2/remote.php is executed instead, adding the Schedule and IMip plugins.

@DeepDiver1975
Member

Oh yes .... sure. The gnome integration uses v1 webdav endpoint. :facepalm:

Mind submitting a pull request?

Thanks a lot

@ctodobom
Contributor

Mind submitting a pull request?

I will submit.

@ctodobom ctodobom added a commit to ctodobom/owncloud-core that referenced this issue Sep 22, 2016
@ctodobom ctodobom fix issue #23600 - mail invites through v1 webdav 462c541
@ctodobom ctodobom referenced this issue in ctodobom/owncloud-core Sep 22, 2016
Merged

fix issue #23600 - mail invites through v1 webdav #1

@brianjmurrell
brianjmurrell commented Sep 22, 2016 edited

So I patched my OC 9.0.4 installation "in situ" with the merged patch but I am still not getting e-mail invitations to invitees through a GOA.

Is there anything more I should need to do than to just apply that patch?

I am still getting e-mail invites when using a Caldav account rather than a GOA account.

@ctodobom
Contributor

@brianjmurrell , As I've stated on my yesterday's message, I'm running nextcloud 10 and while looking to solve this bug got to this thread.

The pull request I've made is a simple copy without testing from the one that worked for me with nextcloud. It is possible that there is more diferences between owncloud and nextcloud, so, I think you should debug a little more before accepting the merge.

@brianjmurrell

@ctodobom That's fair enough. My comment could just be taken as a confirmation that just applying your patch is not enough for owncloud.

@DeepDiver1975
Member

My comment could just be taken as a confirmation that just applying your patch is not enough for owncloud.

@brianjmurrell please double check if ORGANIZER value in an event submitted via a GOA setup matches the email address in the users settings.

@brianjmurrell

@DeepDiver1975 Happy to. Where can I intercept that to see what the value is? I think it goes over the network with SSL so I can't sniff it.

@DeepDiver1975
Member

The event is stored in the db - table oc_calendarobjects

@brianjmurrell

Ahhhh! It's working now! I did indeed have the wrong "From" address selected in the Organiser field in Evolution when creating the event. TBH, I hadn't really ever noticed that one can select an organiser from one's list of e-mail accounts.

So the above mentioned patch does fix this in OC9. Can we get it applied for the next release?

@DeepDiver1975 DeepDiver1975 added a commit that referenced this issue Oct 10, 2016
@ctodobom @DeepDiver1975 ctodobom + DeepDiver1975 [stable9.1] fix issue #23600 - mail invites through v1 webdav (#26188) 3a4f8b6
@ghost
ghost commented Nov 9, 2016

@PVince81 @DeepDiver1975 @jokakilla oC 9.1.2 was released yesterday fixing this issue according to the changelog so this probably could bee closed here.

@creopard
creopard commented Nov 9, 2016 edited

Does not seem to work yet.

Using oC 9.1.2 I created a calendar event on my smartphone and invited someone else, but no invitation was sent.
The result in the caleandar app in oC looks like this:
calendar_details

Question 1: is the prefix "mailto:" supposed to be there?
Question 2: I guess the second line should contain the email adress of the person which was invited, but it's blank

By the way: Modifying this specific appointment and adding a new(!) email adress using the oC calendar web interface sends out an email to the newly invited person immediately.

@JB1985
JB1985 commented Jan 6, 2017

After Update from ownCloud 9.1.1 to 9.1.3 i cant sent mail invitation with Lightning/Thunderbird.

With 9.1.1 it has works.

Any workaround?

@JB1985
JB1985 commented Jan 6, 2017

On iOS10.2 is not working too.

@JB1985
JB1985 commented Jan 6, 2017

Is it again a LDAP problem? If I add a new event, I cant see the field to add a email, but only for LDAP User. If I add a local user I see the field.

bildschirmfoto vom 2017-01-06 14-00-02

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment