1285191 - Lightning 4.7.1.1 and 4.7.2 do not send invite by email to attendees in TB 45.1.1 and 45.2

Status: RESOLVED WORKSFORME

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[Richard Leger]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

Create a new calendar items, press Invite Attendees in the menu... add an attendee, press ok, then Save and Close (in the attendee section list, the notify attendee option is checked marked and greyed out).


Actual results:

Calendar item appears as created in Calendar but the attendees are not notified by email, no email appears in Sent items, not email received by attendees.


Expected results:

While item is created successfully, an email shall be sent automatically to attendees and appears in the list of my sent items.

Comment 1

[[:MakeMyDay]]

Do you have an email identity associated to the calendar?

What calendar type (local, caldav, provider for Google,...) are you using? If this is a caldav calendar, please enable calendar.debug.log and calendar.debug.log.verbose in the config editor, check the error console after TB startup and post the server's reply to the OPTIONS request.

Comment 2

[Richard Leger]

(In reply to [:MakeMyDay] from comment #1)
> Do you have an email identity associated to the calendar?

Yes in Calendar Properties > Email, the email address of my default email (IMAP/SMTP) account appears.

> What calendar type (local, caldav, provider for Google,...) are you using?

After further testing, I can confirm issue only raise only with the remote caldav calendars (Davical server) and not the local calendars (for which notification of attendees by email works fine).

> If this is a caldav calendar, please enable calendar.debug.log and
> calendar.debug.log.verbose in the config editor, check the error console
> after TB startup and post the server's reply to the OPTIONS request.

Ok will try that and revert back shortly.

At the meantime I noticed the following Davical config option is set and set to false in config file of Davical server, seems to sort the issue (may require to deselect calendar, disable it in properties, re-enable it and re-select it for the option change to be taken into account) a priory, but further testing may need to be required to confirm it does not have any side effects.

$c->enable_auto_schedule = false;
Source: http://wiki.davical.org/index.php/Configuration/settings/enable_auto_schedule

My bet would be that the server scheduling capabilities (turn ON by default since months) was simply ignored on client side up to now allowing Thunderbird/Ligthening to still send invite directly via email (scheduling handled client side), but is now (since recent updates) taken into consideration by the client and therefore "fails" to send email notification as this feature is relegated to the server which is not yet able to do so (feature not implemented in Davical). Only end-users on the same Davical server may be able to see created items and confirm attendance directly within the calendar item in their calendar. Davical is not currently able to send email invite to internal and external users (as far as I know).

Comment 3

[Richard Leger]

(In reply to Richard Leger from comment #2)
> (In reply to [:MakeMyDay] from comment #1)
> > If this is a caldav calendar, please enable calendar.debug.log and
> > calendar.debug.log.verbose in the config editor, check the error console
> > after TB startup and post the server's reply to the OPTIONS request.
> 
> Ok will try that and revert back shortly.

As per your request, here is what I get in error console with my Test calendar (Davical CalDav Calendar):

(...)
CalDAV: send: OPTIONS https:// (...)
---
CalDAV: DAV header: 1, 2, 3, access-control, calendar-access, calendar-schedule, extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy
---
CalDAV: Calendar Test supports calendar-auto-schedule
(...)

Is that what you wanted to see?

Comment 4

[Richard Leger]

Additional info...

The DAV header looks similar to an old posted comment from 2011 in a separate non related bug...
https://bugzilla.mozilla.org/show_bug.cgi?id=687051#c2 (Bug 687051 - Lightning does not retrieve scheduling inbox)... so that may confirm that nothing has much changed in Davical with regards to header information and lightening might handle them in a different way since recently...

By default in Davical $c->enable_auto_schedule is set to true since version 0.9.9 and later (false previously). This is the default value which automatically cause the server to append calendar-auto-schedule into the header. When set to false, the calendar-auto-schedule is missing from the header.
We never used version lower than 0.9.9 nor ever set this option explicitly in the configuration file (used only the default value).

Comment 5

[Richard Leger]

For reference, if that may help as well...
Bug 429255 - Lightning not emailing invites for CalDAV calendars

Comment 6

[[:MakeMyDay]]

Thanks for checking - this is want I expected. As you already have noticed, the problem here is the calendar-auto-schedule DAV header presented by the server. If this is advertised, Lightning leaves all of the scheduling operation to the server, irrespectively whether the server can deal with that properly or not in terms of user notification (which is a valid behaviour of Lightning based on RfC 6638 - the server is responsible for scheduling operations by default in a calendar-auto-schedule case).

That said, it's recommended to disable that server configuration if you want to enforce Lightning take care of (email) scheduling, especially if you also want send invitations to users not known by your calendar server and there's no server side option to send scheduling messages to such users.

Comment 7

[Richard Leger]

Any clue why the issue would happen now while the header was provided for months by server without causing issue?

Is it because Lightning is becoming more RFC compliant and now properly parse header to detect server feature and comply with it? Or else?

Comment 8

[[:MakeMyDay]]

I'm not aware of any changes regarding this. In which version did this work differently?

Comment 9

[Richard Leger]

Previous versions than thoses indicated in title of this bug. Unless something was cached in the past and suddenly cleared following recent updates.

Comment 10

[[:MakeMyDay]]

So your're saying this was not an issue with 4.7.0? 4.7.1.1 only received a single patch compared to 4.7.1, which was completely unrelated and 4.7.1 haven't had any.

So if you can confirm it worked for you with 4.7.0, something else must have changed in your setup inbetween.

Comment 11

[Richard Leger]

I would not be able to tell at which version of lightning it started to happen... What I know for sure is that our Davical server has been advertising the same headers for months almost a year and we only started to observe issue recently I would say May Junemore likely since upgrade from TB38 to TB42-45.

We have since changed configuration of ourserver so the header option is no longer sent so client sofware handle fully the invitation.

Following the change server side, it was required to disable cache and calendar in Calendar property for every network Calendar in every user TB client for change to be effective.

Comment 12

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

It looks like you've found a solution to this issue, I am closing the bug. If there is anything left to be done please reopen.