1350838 - Calender appointment with attendees does not ask for mail sending

Status: RESOLVED DUPLICATE of bug 1299610

(Calendar :: General, defect)

Description

[Alberto]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.33 Safari/537.36

Steps to reproduce:

Case 1: On a local calender: Create appointment and invite attendees
Case 2: On a CalDav calender: Create appointment and invite attendees


Actual results:

Case 1: Ask if a mail should be sent "Would you like to send out notification E-Mail now"?
Case 2: Sends the mail automatically


Expected results:


Case 1: I like this behaviour
Case 2: Should also pop up the same dialog

Case 1 and 2 should behave the same way, and always ask.

Remote CalDav calendar seems to delegate in the server to send update mails, which may be incorrect. Local in the other hand don't, and always ask to send update notification mails.

We should have the option to delegate or not, and always ask.

We're using Horde (therefore Sabre.io or SabreDAV underneath - http://sabre.io/dav/) as CalDAV server.
When using WebDAV, for same actions (like when creating an event) it lets me choose whether to send the notification message or not, but not always. Using local calendars ALWAYS let me choose. But when using CalDAV it never let me choose.
Using local calendars get the mail sent into the "sent folder", so it seems that it is Thunderbird the one which sends the mails. Using CalDAV calendars ALWAYS sends the emails but they don't appear into the sent folders. I guess that the CalDAV server itself is sending the mails.
Sabre is supposed to support scheduling and rfc6638 (http://sabre.io/dav/scheduling/).

So, if I, for instance, delete a meeting and don't want the other atendees to be notified, that's impossible.

I've tried to check calendar.caldav.sched.enabled. It was as default. I tried changing it anyway, with no aparent result.
Then, I activated the debug, and saw this line, which may help:
 CalDAV: Server does not support CalDAV scheduling.

Nothing else which seemed interesting.


A way to solve this could be to always send notifications emails from Thunderbird, having the ability to control whether to send them or not, instead of delegating.

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

In the log messages, there must be DAV header from the caldav server, can you check if it contains calendar-auto-schedule? I'd suggest to keep calendar.caldav.sched.enabled at the default value, I believe this feature is more than broken.

If the server supports automatic scheduling and advertises it, then it is up to the server to send out invitations and Lightning will not. There is a sabredav setting somewhere to control that.

Comment 2

[Alberto]

(In reply to Philipp Kewisch [:Fallen] from comment #1)
> In the log messages, there must be DAV header from the caldav server, can
> you check if it contains calendar-auto-schedule? I'd suggest to keep
> calendar.caldav.sched.enabled at the default value, I believe this feature
> is more than broken.
> 
> If the server supports automatic scheduling and advertises it, then it is up
> to the server to send out invitations and Lightning will not. There is a
> sabredav setting somewhere to control that.

So basically we must disable auto-schedule so that Lighting took control?

Comment 3

[max.frei]

Just recentyl migrated from SabreDAV to Apple CalendarServer on Ubuntu 17.04 because Evert announced he is not working on SabreDAV anymore (https://evertpot.com/sabredav-eol/)

I never had this issue with SabreDAV but now with CalenderServer and Lightning 5.4 my CalDAV setup is broken because Lightning won't let me send out neither invitations nor replies to invitations and expects the server to do it.

I tried to find out if I can disable the DAV-Header option calender-schedule or calender-auto-schedule in CalenderServer but so far I failed. Disabling e.g. iMIP doe not help either.

It would be great if this was configurable on Lightning/Thunderbird side just to be more flexible.

Comment 4

[Andre LaBranche]

Implicit scheduling cannot be disabled in CalendarServer. The reason that implicit scheduling exists is because having scheduling logic in the server is vastly preferable to having it spread out across all the clients, mostly for correctness / synchronization reasons. It means the server does more work, changing the scalability profile significantly, but in my experience it has been a huge win to have all the scheduling done using a single implementation.

I'm told that the request for a 'draft' mode support when creating invites is something that has been discussed by the CalDAV standards committee, but so far it does not exist. Clients could emulate this by simply not uploading the event until consent is obtained for emailing external attendees, but of course that means the draft event wouldn't be available to other clients belonging to that user.

Comment 5

[Andre LaBranche]

However, the client can use SCHEDULE-AGENT=CLIENT on the ATTENDEE properties to prevent the server from sending the invites - then it is up to the client to send emails when appropriate. Doing this would be better than what I suggested previously because SCHEDULE-AGENT=CLIENT allows the event to exist on the server, so it is available to other clients belonging to the user.

Comment 6

[max.frei]

Thanks 'dre for your input. Though I'd like to see any server implementation to be configurable as much as possible just to be flexible whenever special scenarios require it, I guess this is not the right place to discuss the server side.

So from Lightning perspective calendar.caldav.sched.enabled set to false should probably add SCHEDULE-AGENT=CLIENT as an attendee of the meeting and then offer to send the email as it does with a purely local calendar, right?

But what about replies to invitations from others? Maybe this is due to a very special setup I am running, but currently I am not offered to send out emails when accepting/denying invitations. Though I am not the creator of the event, would Lightning have to add this attendee anyway?

Comment 7

[max.frei]

Sorry, misread the property part of the SCHEDULE-AGENT=CLIENT.

I checked my .ics files a bit, as they originate from different CalDAV clients. From these first superficial tests I can confirm that Lightning does not honor this property.

Maybe some background:

I use http://caldavsynchronizer.org/ to synchronize an Office365 Exchange calendar to now CalenderServer (formerly SabreDAV). The events coming from Outlook to CalDAV have SCHEDULE-AGENT=CLIENT property set. This makes sense because it is coming from the Outlook/Exchange world.

Still, Lightning does not offer to send out emails on such events.

An event created with Lightning (using Sogo-Connector btw) does not set this property on the attendees and also does not offer to send out emails.

Writing these lines... am I right that this is rather a SoGo-Connector Issue/Setting because I guess it is SoGo creating the .ics files, right?

Comment 8

[Andre LaBranche]

@max.frei - we have surpassed the limit of my knowledge of Lightning, so I will defer to others. I merely dropped in to provide a bit of perspective from the server side about implicit scheduling.

In general, only the organizer is able to add or remove attendees. For some reason I cannot find the specific part of the spec that says this, but it's probably in here somewhere: https://icalendar.org/RFC-Specifications/CalDAV-Scheduling-RFC-6638/.

... so yeah, I think you've come to a reasonable conclusion.

Note that the rules which gate the ability to create / update / delete *properties* may be distinct from the rules for operating on the *parameters* of those properties. More info about SCHEDULE-AGENT: https://icalendar.org/CalDAV-Scheduling-RFC-6638/7-1-schedule-agent-parameter.html

Comment 9

[max.frei]

Thanks again @Andre.

Just to update my assumptions. Just found out that CalDAV is directly implemented in Lightning and I only use it for CardDAV. Yeah, shame on me. So this is probably still the correct thread :-)

Anyway, as soon as I have a CalDAV calendar configured also local calendars are affected. To be able to send out emails on client side I had to completely unsubscribe from the CalDAV calendar again. Even when I told Lightning to put the event into the local calendar. So there is something buggy here.

Also, I guess it is how Lightning handles this option as soon as there is a calendar with the scheduling DAV HTTP header because with SabreDAV I never had this issue and if I see this correctly, SabreDAV does not set a DAV HTTP header at all.

Well, you are right, will leave it to the Lightning Pros from here on...

Comment 10

[[:MakeMyDay]]

Thank you. We already have bug 1299610 to introduce the opportunity to force client-side scheduling if the server advertises auto scheduling capability.