Closed jokakilla closed 6 years ago
@DeepDiver1975 enhancement ? Or regression ? Not sure if the calendar app ever sent any invitations ?
afaik we did not send invitations in the past - in addition we explicitly tested this feature for 9.0 -> most probably a setup issue
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
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.
Thanks...It's possible to share the appointment with K9-Mail which then creates an email with an ICS attachment.
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.
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.
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.
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.
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.
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?
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?
And with evolution the organizer property is not filled :cry:
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.
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.
maybe @evert can bring some additional light into this - thx
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?
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 ...
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.
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
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
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?
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.
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.
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
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.
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.
Form my understanding pointing fingers is not the way we want work.
Hi!
Few things I take from this thread, not sure if I'm hitting home:
ORGANIZER
is required for schedulingORGANIZER
or one of the ATTENDEES
.ATTENDEE
without ORGANIZER
is afaik meaningless and possibly invalid iCalendar.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:
ORGANIZER
is required for scheduling- 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 theATTENDEES
.- In iCalendar,
ATTENDEE
withoutORGANIZER
is afaik meaningless and possibly invalid iCalendar.- 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
Yes but it needs to match the current users' address specified in the system
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.
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
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?
FWIW: I used GOA to add my account to Evolution.
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.
If @DeepDiver1975 says that it's correct then I feel that this might be an owncloud bug, not an evolution one.
Organizer is sent from evolution for non-goa calendars for me - invites are sent. hmmmm ....
We need to debug this further
@brianjmurrell can you please setup the calendar in evolution directyl without GOA and retry? THX
@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.
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.
okay - I'll debug this further tomorrow - but it looks to be GOA specific.
@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.
Thanks a lot @dmfs
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.
@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?
Not yet 😭
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?
I wonder if there has been any progress on the GOA account flavour of this problem yet?
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?