User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160728203720 Steps to reproduce: Last upgrade to thunderbird 45.2 forced me to upgrade also lightning to 4.7. Actual results: Scenario UBUNTU 16.04 THUNDERBIRD 45.2 LIGHTNING 4.7 Last upgrade to thunderbird 45.2 it forced me to upgrade also lightning to 4.7. After that when I creat event and add invitee to any event, then thunderbir does not send email invitations. Regards. Expected results: Sent the email invitation to meeting / event

Are there any messages in the error console when reproducing the issue? Have you made sure you have assigned an email identity to the calendar, you're trying to create an event in? Does creating an event without attendees work for you?

Hi, "Are there any messages in the error console when reproducing the issue?" Yes Timestamp: 01/09/16 02:26:56 Warning: Use of getPreventDefault() is deprecated. Use defaultPrevented instead. Source File: chrome://calendar/content/calendar-event-dialog.xul Line: 0 Timestamp: 01/09/16 02:26:59 Warning: Use of Mutation Events is deprecated. Use MutationObserver instead. Source File: chrome://calendar/content/calendar-event-dialog-attendees.js Line: 32 Timestamp: 01/09/16 02:28:14 Warning: Use of getPreventDefault() is deprecated. Use defaultPrevented instead. Source File: view-source:chrome://calendar/content/calendar-event-dialog-attendees.js Line: 0 The calendar has already an email identity. Event without attendees works fine, that means it shows the event in the calendar as usual. The only problem is when it has at least 1 attendee. It does not send the email with the invitation. In previous versions Thunderbird gave a pop up asking if it should send the confirmation with Microsoft compatibility. But in this new version, the pup up never shows up nor the email is sent. Regards, Giuseppe

What other addons have you installed? Does this also occur if you have disabled all of them but Lightning?

Yes another addons are installed Lighning, Enigmail, Folderpane tools, ImportExporttools, Inverse SoGo Connetor, Messaging Menu and Unity Launcher Integration, owncloud for firelink. I disabled all of them except Lightning, still not working, with following results: When I create an event got this in error console Timestamp: 01/09/16 09:02:00 Warning: Use of getPreventDefault() is deprecated. Use defaultPrevented instead. Source File: chrome://calendar/content/calendar-event-dialog.xul Line: 0 When I click on INVITE ATTENDEES Button I got this in the error console Timestamp: 01/09/16 09:04:05 Warning: Use of Mutation Events is deprecated. Use MutationObserver instead. Source File: chrome://calendar/content/calendar-event-dialog-attendees.js Line: 32 When I click the SAVE EVENT BUTTON, no alarm in the error console is generated. No mail was sent out. Regards.

This is strange. Have you made sure to restart Thunderbird after disabling all of the addons but Lightning? I assume you installed Thunderbird and Lightning from the Ubuntu package manager? Can you try the same with Thunderbird downloaded from the Mozilla website (which comes bundled with Lightning, so there's no need to install Lightning seperately)?

Before you try that, one question: you mentioned to use sogo connector - is this a caldav calendar, you're creating the event in? If so, have you made sure the server does not advertise serverside scheduling? In that case, Lightning will not take care of tsending invitations ut leaves it to the server to do so. If you don't know aout the server configuration, you can enable calendar.deug.log and calendar. deug.log.verbose and restart Thunderbird. Then check the error console. There should have been some communication with the caldav server. If the server indicates calendar-auto-schedule capability, you have serverside scheduling enabled.

Hi, you are right. I am using OWNCLOUD 9 server which now is capable to send emails actually. Yes we are using a CALDAV connection with the server. But the point is it would be great in Thunderbird -> Lightning if we can decide who is responsible for sending email schedule. I prefer Thunderbird because we will have an email in the SENT box. When we do through CALDAV OWNCLOUD we do not have any visual evidence that the email was sent. Owncloud 8 does not had this feature, but it should have an option in thunderbird to select the email sent out strategy. Regards.

Just to be more clear. No matter if owncloud version is 8 or 9, Thunderbird should have the option to decide. Regards. Giuseppe

Thanks Guiseppe for providing the information. When looking at the code, this seems to be a bug / imcomplete implementation in Lightning. Can you please do the following: 1. enable calendar.debug.log and calendar.debug.log.verbose in the advanced preferences 2. restart Thunderbird 3. open the error console and capture the initial communication of Lightning with the Ownclood server, which should include at least the OPTIONS request and the server reply to it. 4. create a new event in the owncloud calendar, add one or more attendees and save & close 5. capture all of the messages occuring the error console starting with saving the event. 6. attach the information from 2 and 6 to this bug (in 4.7 you can just copy message by message - if you make screenshots instead, please make sure that all information appearing in the log is visible, also when scrolling). After you have done so, you can try to disable the serverside scheduling in the owncloud configuration as a workaround, if that is possible.

Thanks for your support. Here is initial communication of Lightning with the Ownclood server (means point 3). CalDAV: send: <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:resourcetype/><D:owner/><D:current-user-principal/><D:supported-report-set/><C:supported-calendar-component-set/><CS:getctag/></D:prop></D:propfind> CalDAV: Status 207 on initial PROPFIND for calendar NewCrearte CalDAV: Authentication scheme for NewCrearte is Basic CalDAV: recv: <?xml version="1.0"?> <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <d:response> <d:href>/owncloud/remote.php/dav/calendars/admin/personal/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> <cal:calendar/> </d:resourcetype> <d:owner> <d:href>/owncloud/remote.php/dav/principals/users/admin/</d:href> </d:owner> <d:current-user-principal> <d:href>/owncloud/remote.php/dav/principals/users/admin/</d:href> </d:current-user-principal> <d:supported-report-set> <d:supported-report> <d:report> <d:sync-collection/> </d:report> </d:supported-report> <d:supported-report> <d:report> <d:expand-property/> </d:report> </d:supported-report> <d:supported-report> <d:report> <d:principal-property-search/> </d:report> </d:supported-report> <d:supported-report> <d:report> <d:principal-search-property-set/> </d:report> </d:supported-report> <d:supported-report> <d:report> <cal:calendar-multiget/> </d:report> </d:supported-report> <d:supported-report> <d:report> <cal:calendar-query/> </d:report> </d:supported-report> <d:supported-report> <d:report> <cal:free-busy-query/> </d:report> </d:supported-report> <d:supported-report> <d:report> <oc:filter-comments/> </d:report> </d:supported-report> </d:supported-report-set> <cal:supported-calendar-component-set> <cal:comp name="VEVENT"/> <cal:comp name="VTODO"/> </cal:supported-calendar-component-set> <cs:getctag>http://sabre.io/ns/sync/112</cs:getctag> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> </d:multistatus> CalDAV: Collection has webdav sync support Adding supported items: VEVENT,VTODO for calendar: NewCrearte CalDAV: Found principal url from DAV:current-user-principal /owncloud/remote.php/dav/principals/users/admin/ CalDAV: send: OPTIONS http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/ CalDAV: DAV header: 1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, calendar-access, calendar-proxy, calendar-auto-schedule, calendarserver-subscribed, oc-resource-sharing, addressbook CalDAV: Calendar NewCrearte supports calendar-auto-schedule CalDAV: send: PROPFIND http://cloud.creartesoluciones.com/owncloud/remote.php/dav/principals/users/admin/ <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><C:calendar-home-set/><C:calendar-user-address-set/><C:schedule-inbox-URL/><C:schedule-outbox-URL/></D:prop></D:propfind> CalDAV: recv: <?xml version="1.0"?> <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <d:response> <d:href>/owncloud/remote.php/dav/principals/users/admin/</d:href> <d:propstat> <d:prop> <cal:calendar-home-set> <d:href>/owncloud/remote.php/dav/calendars/admin/</d:href> </cal:calendar-home-set> <cal:calendar-user-address-set> <d:href>mailto:gnocera@creartesoluciones.com</d:href> <d:href>/owncloud/remote.php/dav/principals/users/admin/</d:href> </cal:calendar-user-address-set> <cal:schedule-inbox-URL> <d:href>/owncloud/remote.php/dav/calendars/admin/inbox/</d:href> </cal:schedule-inbox-URL> <cal:schedule-outbox-URL> <d:href>/owncloud/remote.php/dav/calendars/admin/outbox/</d:href> </cal:schedule-outbox-URL> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> </d:multistatus> CalDAV: send(http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/): <?xml version="1.0" encoding="UTF-8"?> <sync-collection xmlns="DAV:"><sync-token>http://sabre.io/ns/sync/112</sync-token><sync-level>1</sync-level><prop><getcontenttype/><getetag/></prop></sync-collection> CalDAV: webdav-sync Token: http://sabre.io/ns/sync/112 CalDAV: recv: <d:multistatus> <d:sync-token>http://sabre.io/ns/sync/112</d:sync-token> </d:multistatus> CalDAV: New webdav-sync Token: http://sabre.io/ns/sync/112 aChangeLogListener=[xpconnect wrapped calIGenericOperationListener] calendarURI=http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/ iscached=true this.mQueuedQueries.length=0 [calCachedCalendar] replayChangesOn finished. [calCachedCalendar] sync queue empty. 2016-09-26 10:54:03 gloda.NS WARN new proc ignoring attrib: id

Hello, And this is the log for points 4 and 5, starting from the moment I click on the calendar icon. - click on the calendar icon button NO events - Create the new event by dragging with the mouse over the calendar directly CalDAV: itemUri.spec = http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf.ics CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:America/Bogota BEGIN:STANDARD TZOFFSETFROM:-0500 TZOFFSETTO:-0500 TZNAME:COT DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20160926T163028Z LAST-MODIFIED:20160926T163028Z DTSTAMP:20160926T163028Z UID:3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf SUMMARY:New Event DTSTART;TZID=America/Bogota:20160927T130000 DTEND;TZID=America/Bogota:20160927T140000 TRANSP:OPAQUE END:VEVENT END:VCALENDAR CalDAV: recv: CalDAV: Item added to NewCrearte successfully CalDAV: send(http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/): <?xml version="1.0" encoding="UTF-8"?> <C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/owncloud/remote.php/dav/calendars/admin/personal/3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf.ics</D:href></C:calendar-multiget> CalDAV: recv: <d:multistatus> <d:response> <d:href>/owncloud/remote.php/dav/calendars/admin/personal/3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf.ics</d:href> <d:propstat> <d:prop> <d:getetag>"2d6a6115f835ac24660c54f93f799624"</d:getetag> <cal:calendar-data>BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:America/Bogota BEGIN:STANDARD TZOFFSETFROM:-0500 TZOFFSETTO:-0500 TZNAME:COT DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20160926T163028Z LAST-MODIFIED:20160926T163028Z DTSTAMP:20160926T163028Z UID:3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf SUMMARY:New Event DTSTART;TZID=America/Bogota:20160927T130000 DTEND;TZID=America/Bogota:20160927T140000 TRANSP:OPAQUE END:VEVENT END:VCALENDAR </cal:calendar-data> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> </d:multistatus> aChangeLogListener=undefined calendarURI=http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/ iscached=true this.mQueuedQueries.length=0 - OPEN THE NEW EVENT and set a test meeting as TESTGIUSEPPE, including attendee emails destinations Timestamp: 26/09/16 11:31:32 Warning: Use of getPreventDefault() is deprecated. Use defaultPrevented instead. Source File: chrome://calendar/content/calendar-event-dialog.xul Line: 0 Timestamp: 26/09/16 11:32:08 Warning: Use of Mutation Events is deprecated. Use MutationObserver instead. Source File: chrome://calendar/content/calendar-event-dialog-attendees.js Line: 32 CalDAV: send (Originator=mailto:gnocera@creartesoluciones.com,Recipient=mailto:gnocera@creartesoluciones.com): BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20160926T163208Z ORGANIZER:mailto:gnocera@creartesoluciones.com DTSTART:20160927T050000Z DTEND:20161013T050000Z UID:22bc81ee-a94e-415d-be7d-4c896ee4d751 ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail to:gnocera@creartesoluciones.com END:VFREEBUSY END:VCALENDAR CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <cal:schedule-response xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <cal:response> <cal:recipient> <d:href>mailto:gnocera@creartesoluciones.com</d:href> </cal:recipient> <cal:request-status>3.7;Could not find principal</cal:request-status> </cal:response> </cal:schedule-response> CalDAV: Got status 3.7;Could not find principal in response to freebusy query for NewCrearte CalDAV: send (Originator=mailto:gnocera@creartesoluciones.com,Recipient=mailto:crearte057@gmail.com): BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20160926T163212Z ORGANIZER:mailto:gnocera@creartesoluciones.com DTSTART:20160927T050000Z DTEND:20161013T050000Z UID:87dbfa91-c8a7-4fcc-bc42-1c5efa6db5b5 ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail to:crearte057@gmail.com END:VFREEBUSY END:VCALENDAR CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <cal:schedule-response xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <cal:response> <cal:recipient> <d:href>mailto:crearte057@gmail.com</d:href> </cal:recipient> <cal:request-status>3.7;Could not find principal</cal:request-status> </cal:response> </cal:schedule-response> CalDAV: Got status 3.7;Could not find principal in response to freebusy query for NewCrearte CalDAV: send (Originator=mailto:gnocera@creartesoluciones.com,Recipient=mailto:crearte057@gmail.com): BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20160926T163214Z ORGANIZER:mailto:gnocera@creartesoluciones.com DTSTART:20160927T050000Z DTEND:20161013T050000Z UID:4593ee1b-d79a-4eca-aeea-e4add3f9b67b ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail to:crearte057@gmail.com END:VFREEBUSY END:VCALENDAR CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <cal:schedule-response xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <cal:response> <cal:recipient> <d:href>mailto:crearte057@gmail.com</d:href> </cal:recipient> <cal:request-status>3.7;Could not find principal</cal:request-status> </cal:response> </cal:schedule-response> CalDAV: Got status 3.7;Could not find principal in response to freebusy query for NewCrearte CalDAV: send (Originator=mailto:gnocera@creartesoluciones.com,Recipient=mailto:gerencia@creartesoluciones.com): BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20160926T163220Z ORGANIZER:mailto:gnocera@creartesoluciones.com DTSTART:20160927T050000Z DTEND:20161013T050000Z UID:4d9d108e-cc9d-4228-8781-a10d65f64dc8 ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail to:gerencia@creartesoluciones.com END:VFREEBUSY END:VCALENDAR CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <cal:schedule-response xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <cal:response> <cal:recipient> <d:href>mailto:gerencia@creartesoluciones.com</d:href> </cal:recipient> <cal:request-status>3.7;Could not find principal</cal:request-status> </cal:response> </cal:schedule-response> CalDAV: Got status 3.7;Could not find principal in response to freebusy query for NewCrearte CalDAV: send (Originator=mailto:gnocera@creartesoluciones.com,Recipient=mailto:gerencia@creartesoluciones.com): BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20160926T163222Z ORGANIZER:mailto:gnocera@creartesoluciones.com DTSTART:20160927T050000Z DTEND:20161013T050000Z UID:288b0f6e-05c2-449d-963f-ef03b57e96da ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail to:gerencia@creartesoluciones.com END:VFREEBUSY END:VCALENDAR CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <cal:schedule-response xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns"> <cal:response> <cal:recipient> <d:href>mailto:gerencia@creartesoluciones.com</d:href> </cal:recipient> <cal:request-status>3.7;Could not find principal</cal:request-status> </cal:response> </cal:schedule-response> CalDAV: Got status 3.7;Could not find principal in response to freebusy query for NewCrearte - SAVE AND CLOSE THE EVENT CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:America/Bogota BEGIN:STANDARD TZOFFSETFROM:-0500 TZOFFSETTO:-0500 TZNAME:COT DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20160926T163028Z LAST-MODIFIED:20160926T163509Z DTSTAMP:20160926T163509Z UID:3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf SUMMARY:TESTGIUSEPPE ORGANIZER;RSVP=TRUE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:gnocera@creartesol uciones.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:crear te057@gmail.com ATTENDEE;RSVP=TRUE;CN=gerencia@creartesoluciones.com;PARTSTAT=NEEDS-ACTION ;ROLE=REQ-PARTICIPANT:mailto:gerencia@creartesoluciones.com DTSTART;TZID=America/Bogota:20160927T130000 DTEND;TZID=America/Bogota:20160927T140000 TRANSP:OPAQUE DESCRIPTION:TEST GIUSEPPE X-MOZ-GENERATION:1 BEGIN:VALARM ACTION:DISPLAY TRIGGER;VALUE=DURATION:-PT15M DESCRIPTION:Default Mozilla Description END:VALARM END:VEVENT END:VCALENDAR CalDAV: recv: CalDAV: Item modified successfully on NewCrearte CalDAV: send(http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/): <?xml version="1.0" encoding="UTF-8"?> <C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/owncloud/remote.php/dav/calendars/admin/personal/3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf.ics</D:href></C:calendar-multiget> CalDAV: recv: <d:multistatus> <d:response> <d:href>/owncloud/remote.php/dav/calendars/admin/personal/3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf.ics</d:href> <d:propstat> <d:prop> <d:getetag>"6da70708b145809c89ca87eabc2e93c5"</d:getetag> <cal:calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN BEGIN:VTIMEZONE TZID:America/Bogota BEGIN:STANDARD TZOFFSETFROM:-0500 TZOFFSETTO:-0500 TZNAME:COT DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20160926T163028Z LAST-MODIFIED:20160926T163509Z DTSTAMP:20160926T163509Z UID:3e6d0d82-43be-4fd8-ac59-c64f34cbb2cf SUMMARY:TESTGIUSEPPE ORGANIZER;RSVP=TRUE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:gnocera@creartesolu ciones.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;SCHEDULE-STAT US=1.1:mailto:crearte057@gmail.com ATTENDEE;RSVP=TRUE;CN=gerencia@creartesoluciones.com;PARTSTAT=NEEDS-ACTION; ROLE=REQ-PARTICIPANT;SCHEDULE-STATUS=1.1:mailto:gerencia@creartesoluciones .com DTSTART;TZID=America/Bogota:20160927T130000 DTEND;TZID=America/Bogota:20160927T140000 TRANSP:OPAQUE DESCRIPTION:TEST GIUSEPPE X-MOZ-GENERATION:1 BEGIN:VALARM ACTION:DISPLAY TRIGGER;VALUE=DURATION:-PT15M DESCRIPTION:Default Mozilla Description END:VALARM END:VEVENT END:VCALENDAR </cal:calendar-data> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> </d:multistatus> aChangeLogListener=undefined calendarURI=http://cloud.creartesoluciones.com/owncloud/remote.php/dav/calendars/admin/personal/ iscached=true this.mQueuedQueries.length=0 NOTICE THAT the item was successfully modified on the owncloud server calendar Regards, Giuseppe

Thank you Guiseppe. This needs a little more work then expected initially - I'm going to mark this as enhancement request as the requested behaviour was not implemented before.

Philipp, this is completely untested code, I'm just uploading it to get some feedback on the approach.

The attached patch has a bug in it iirc,, but as I just want to have feedback before cleaning up, I spare uploading and updated version for now. However, I set this for tracking for 5.4 - and as it has l10n impact a feedback before string freeze would be nice.

Comment on attachment 8795428 [details] [diff] [review] EnableEnforcingEmailSchedulingOnCaldav-V1.diff Review of attachment 8795428 [details] [diff] [review]: ----------------------------------------------------------------- You probably know your way around email scheduling better than I do, so I don't know if I can make a good comment on this at the moment. If what you are doing follows the spec then the approach looks fine to me. A few comments: ::: calendar/base/modules/calItipUtils.jsm @@ +906,4 @@ > }); > + > + // according to RfC 6638, the following items must not be exposed in client side > + // scheduling messages, so let's remove it if present Can you give me a pointer to this? I do remember there was something about removing these parameters, but I don't quite recall. I would have thought that these properties, especially SCHEDULE-AGENT, would be needed when sending around messages to ensure the right agent is selected. ::: calendar/locales/en-US/chrome/lightning/lightning.dtd @@ +37,5 @@ > <!ENTITY lightning.menu.eventtask.accesskey "n"> > > <!-- properties dialog, calendar creation wizard --> > +<!ENTITY lightning.calendarproperties.email.label "E-Mail:"> > +<!ENTITY lightning.calendarproperties.forceEmailScheduling.label "Enforce email based scheduling"> I think this might be misleading, although at the moment I don't have a good suggestion to mitigate. The average user will of course want email scheduling and always enable it. The fact that the user would also get emails from the server is not clear. For the very least I'd turn this around and use "Disable server-side scheduling". While that has the same problem vice versa, it would cause only people that know what they are doing to enable it.

Thanks for the feedback, please find the answers to your questions below. (In reply to Philipp Kewisch [:Fallen] from comment #16) > Can you give me a pointer to this? I do remember there was something about > removing these parameters, but I don't quite recall. > > I would have thought that these properties, especially SCHEDULE-AGENT, would > be needed when sending around messages to ensure the right agent is selected. This is defined in the respective chapters in https://tools.ietf.org/html/rfc6638#section-7 n.b.: this is about the ics in the imip message, not the one synced with the caldav server. > I think this might be misleading, although at the moment I don't have a good > suggestion to mitigate. The average user will of course want email > scheduling and always enable it. The fact that the user would also get > emails from the server is not clear. > > For the very least I'd turn this around and use "Disable server-side > scheduling". While that has the same problem vice versa, it would cause only > people that know what they are doing to enable it. The main question here is whether or not we want to expose this to the user by the UI or prefer a hidden preference. I think, a UI pref makes sense here. We could limit exposing the option to those calendar, which advertise auto-scheduling, but as the benefit is limited and it would add complexity to the wizard because we would need to detect the server capabilities already from within the wizard, so I would refrain from doing so. That said, making this an opt-out verbally, is probably the best compromise to not confuse the average user. I will prepare a patch for review then.

I did some tests with a Davial server and the patch still needs some polishing. But as it only has a single string, I still consider it a late-l10n candidate for now.

This bug missed the train for ESR late-l10n changes. However, I'll keep tracking for 5.4 as we can at least ship with a hidden pref once the patch is in shape.

(In reply to [:MakeMyDay] from comment #19) > This bug missed the train for ESR late-l10n changes. However, I'll keep tracking for 5.4 as we can at least ship with a hidden pref once the patch is in shape. Hello! Thanks for the patch :) Any schedule for the release?

The patch is not yet ready to land. But there is still a little chance this might make it for TB 52.

If someone (like me) has this issues using next/owncloud. There is a solution on the cloud server site to avoid server site scheduling and return to TB long time practise, see: https://github.com/nextcloud/calendar/issues/170#issuecomment-274962983

Any chance you can finish up this patch? I know time is short, but it looks like you already made a great start!

It is still in my patch queue and but I can't promise any eta - not likely to happen in the next couple of weeks.

The patches enable the capability to enable email based scheduling for events stored on caldav servers, which have autoscheduling enabled. This is tested successfully on a Davical server and all tests passed locally (though our caldav test coverage is effectively not existing). The option currently cannot be enabled in the calendar wizard directly, because this would require an options request before loading the respective page of the wizard to decide whether or not to offer this capability. Hopefully, this can be added along with bug 306495.

Fallen, any chance to get this reviewed and landed before the upcoming merges? I would like to see some beta test coverage on this with more servers earlier then later. I know the UI part is interfering with the dialog conversion in current GSoC, but given we have no really good test coverage on caldav, I would rate the gain of getting more and early tester feedback higher then the extra effort for converting another bit for the properties dialog.

Comment on attachment 8876414 [details] [diff] [review] EnableEnforcingEmailSchedulingOnCaldav-Processing-V1.diff Review of attachment 8876414 [details] [diff] [review]: ----------------------------------------------------------------- I found a few potential issues, please check. r+wc ::: calendar/base/content/dialogs/calendar-dialog-utils.js @@ +705,5 @@ > + let identity = aItem.calendar.getProperty("imip.identity"); > + let orgEmail = identity && > + identity.QueryInterface(Components.interfaces.nsIMsgIdentity).email; > + let organizerAction = aItem.organizer && orgEmail && > + aItem.organizer.id == "mailto:" + orgEmail; Trailing spaces ::: calendar/base/modules/calProviderUtils.jsm @@ +216,5 @@ > /** > * Gets the iTIP/iMIP transport if the passed calendar has configured email. > */ > cal.getImipTransport = function(aCalendar) { > + cal.ASSERT(aCalendar, "no calendar!", Components.results.NS_ERROR_INVALID_ARG); Were you getting this case during testing? I'd suggest to look at the calling code to ensure a calendar is passed, as an exception will be thrown anyway a line down if aCalendar == null I don't think we need this assertion if the calling code is safe. ::: calendar/base/src/calItipItem.js @@ +136,5 @@ > + aCalUser.deleteProperty("SCHEDULE-FORCE-SEND"); > + aCalUser.deleteProperty("SCHEDULE-STATUS"); > + }; > + item.getAttendees({}).forEach(removeSchedulingParams); > + // we're graceful here as some PUBLISHed events may violate RfC by having no organizer Trailing spaces ::: calendar/providers/caldav/calDavCalendar.js @@ +195,5 @@ > get offlineCachedProperties() { > return ["mAuthScheme", "mAuthRealm", "mHasWebdavSyncSupport", > "mCtag", "mWebdavSyncToken", "mSupportedItemTypes", > "mPrincipalUrl", "mCalHomeSet", > + "mShouldPollInbox", "mHasAutoScheduling", "mHaveScheduling", I don't think you can just change this. These properties are read from the calendar metadata, so the old property will stay there until they are next written, and the new property won't be restored correctly and stay at the default value. Can you double check there are no unintended side-effects? @@ +2701,5 @@ > + case "REQUEST": > + case "CANCEL": > + case "ADD": > + aItem.getAttendees({}).forEach((aAttendee) => { > + if (aAttendee.getProperty("SCHEDULE-AGENT") == "CLIENT") { What happens on a mix of SERVER/CLIENT scheduling? I think this can occur e.g. when inviting external guests to meetings. The attendees from the same company would have SCHEDULE-AGENT=SERVER while the external ones have SCHEDULE-AGENT=CLIENT. If this is a simplification due to the limitations of canNotify I'd suggest to add a comment somewhere to explain. @@ +2768,5 @@ > + // code should only route scheduling request to this method, on which the server > + // needs to take responsibility. But I leave it for now. If the server isn't able to > + // fulfill the scheduling, we better should catch that on a per attendee level based > + // on the SCHEDULE-AGENT value present when reretrieving the item after storing > + // serverside Trailing spaces

Comment on attachment 8876415 [details] [diff] [review] EnableEnforcingEmailSchedulingOnCaldav-UI-V1.diff Review of attachment 8876415 [details] [diff] [review]: ----------------------------------------------------------------- r- for now because I'd like to take a look at the overlay code, see comment below. ::: calendar/lightning/content/lightning-utils.js @@ +83,5 @@ > let selItem = document.getElementById("email-identity-menulist").selectedItem; > if (!imipIdentityDisabled && selItem) { > sel = selItem.getAttribute("value"); > } > + return sel; If you are returning sel here, you will have to return a value above in the !gCalendar case (consistent-return rule). While you are here, can you add a jsdoc header for this function? @@ +86,5 @@ > } > + return sel; > +} > + > +function ltnSaveMailIdentitySelection() { I would also appreciate a jsdoc header for any new functions you add. @@ +97,5 @@ > gCalendar.setProperty("imip.identity.key", sel == "none" ? "" : sel); > } > + > +function ltnInitForceEmailScheduling() { > + if (!gCalendar || gCalendar.type != "caldav") { If this is caldav-only I think it would make sense to add it as an overlay from the caldav provider @@ +112,5 @@ > + checkbox.removeAttribute("checked"); > + } > + // TODO: also check, whether an email identity is set -> ltnGetMailIdentitySelection() != "none" > + // let calEnabled = document.getElementById("calendar-enabled-checkbox"); > + // calEnabled = calEnabled.setAttribute("checked") == "true"; TODO comment, did you want to leave this in? Also, somthing is fishy with the indent here.

I can confirm this bug. As you already working on a solution this brings up the question when it will be available. Is there any schedule for the next release including this fix? Thank you!

Updated patch with comments addressed. I'm asking for review again, because I did some changes to the previous processing approach. > > What happens on a mix of SERVER/CLIENT scheduling? I think this can occur e.g. > when inviting external guests to meetings. The attendees from the same company > would have SCHEDULE-AGENT=SERVER while the external ones haveSCHEDULEAGENT=CLIENT. > The UI will provide only an option for server or chlient side scheduling - mixed operations are not supported for now. We can extend this in future on by capturing error codes of server-side scheduling operations when re-retrieving the item. In general, the server should only advertise that feature, if it is capable to do the operation.

Updated patch with separated out caldav specific UI code to the provider.

Philipp, can you please give these reviews kind of priority, so we can include these patches into TB58 beta? Given to our not existing automated test coverage for caldav, it would be unfortunate to let this hit beta first time with TB59.

Comment on attachment 8921602 [details] [diff] [review] EnableEnforcingEmailSchedulingOnCaldav-Processing-V2.diff Review of attachment 8921602 [details] [diff] [review]: ----------------------------------------------------------------- lgtm. As we have eslint running on treeherder now, can you make sure it passes? If you can't get that to work locally, you can push to try with an empty (or random) commit message and include a file try_task_config.json in the root of the repo that contains just ["source-test-mozlint-eslint"] ::: calendar/providers/caldav/calDavCalendar.js @@ +2748,5 @@ > + if (this.getProperty("forceEmailScheduling")) { > + return doImipScheduling(this, aRecipients); > + } > + > + if (this.hasAutoScheduling || this.hasScheduling) { Whitespaces at EOL

Comment on attachment 8921603 [details] [diff] [review] EnableEnforcingEmailSchedulingOnCaldav-UI-V2.diff Review of attachment 8921603 [details] [diff] [review]: ----------------------------------------------------------------- r+ with these changes. On the strings, I know this will be a challenge but if you find a good way to hide the technical details (client side, server side, autoscheduling) without making it impossible for the power user to know what to enable, that would be great. ::: calendar/lightning/content/lightning-calendar-creation.xul @@ +21,5 @@ > align="center" > insertafter="customize-suppressAlarms-row"> > <label value="&lightning.calendarproperties.email.label;" > control="email-identity-menulist"/> > + <menulist id="email-identity-menulist" Instead of providing an empty hook, I'd probably just go with doing this in the hooked code: document.getElementById("email-identity-menulist").addEventListener("command", (event) => { ... }); ::: calendar/lightning/content/lightning-utils.js @@ +86,3 @@ > let sel = "none"; > + if (gCalendar) { > + sel = "none"; No need to set sel to none again if you've done so in the init. ::: calendar/locales/en-US/chrome/lightning/lightning.dtd @@ +40,5 @@ > +<!-- LOCALIZATON NOTE(lightning.calendarproperties.email.label, > + lightning.calendarproperties.forceEmailScheduling.label) > + These strings are used in the calendar wizard and the calendar properties dialog, but are only > + displayed when setting/using a caldav calendar --> > +<!ENTITY lightning.calendarproperties.email.label "E-Mail:"> We should be consistent w.r.t. use of email vs e-mail. I don't know what is prevalent though. My personal taste is email, if there is consistence in Thunderbird let's go with what they use. @@ +41,5 @@ > + lightning.calendarproperties.forceEmailScheduling.label) > + These strings are used in the calendar wizard and the calendar properties dialog, but are only > + displayed when setting/using a caldav calendar --> > +<!ENTITY lightning.calendarproperties.email.label "E-Mail:"> > +<!ENTITY lightning.calendarproperties.forceEmailScheduling.label "Enforce client-side email based scheduling"> Maybe "Prefer client-side email based scheduling" is better understandable? @@ +46,5 @@ > +<!-- LOCALIZATON NOTE(lightning.calendarproperties.forceEmailScheduling.tooltiptext1, > + lightning.calendarproperties.forceEmailScheduling.tooltiptext2) > + - tooltiptext1 is used in the calendar wizard when setting a new caldav calendar > + - tooltiptext2 is used in the calendar properties dialog for caldav calendars --> > +<!ENTITY lightning.calendarproperties.forceEmailScheduling.tooltiptext1 "For now, you can only enable this after setting up this calendar in the it's property dialog if the calendar server has enabled server-side autoscheduling."> Something is wrong here ("in the it's"). Can we also rephrase this to tell the user what they need to set up? @@ +47,5 @@ > + lightning.calendarproperties.forceEmailScheduling.tooltiptext2) > + - tooltiptext1 is used in the calendar wizard when setting a new caldav calendar > + - tooltiptext2 is used in the calendar properties dialog for caldav calendars --> > +<!ENTITY lightning.calendarproperties.forceEmailScheduling.tooltiptext1 "For now, you can only enable this after setting up this calendar in the it's property dialog if the calendar server has enabled server-side autoscheduling."> > +<!ENTITY lightning.calendarproperties.forceEmailScheduling.tooltiptext2 "This option is only available, if the calendar server has enabled server-side autoscheduling, otherwise client-side email based scheduling will be used anyway."> I don't think the first comma is necessary here. Maybe we can split this up to drop use of "anyway" (given it is accurate): "This option is only available if the calendar server has enabled server-side autoscheduling. Client side email based scheduling will be used as a fallback." ::: calendar/providers/caldav/moz.build @@ +3,5 @@ > # License, v. 2.0. If a copy of the MPL was not distributed with this > # file, You can obtain one at http://mozilla.org/MPL/2.0/. > > +DIRS += [ > + 'public', Any specific reason for this change?

Updated and linted patch with comment considered. Carrying forward r+.

Updated linted patch with comments considered except the monkeypathing thing as discussed on irc. I'm rerequesting review because this version introduces an additional notification, if a user doesn't select an email identity.

Comment on attachment 8929726 [details] [diff] [review] EnableEnforcingEmailSchedulingOnCaldav-UI-V3.diff Review of attachment 8929726 [details] [diff] [review]: ----------------------------------------------------------------- One minor nit: ::: calendar/locales/en-US/chrome/lightning/lightning.properties @@ +213,5 @@ > integrationRestartAccessKey=R > integrationUndoButton=Undo > integrationUndoAccessKey=U > + > +# LOCALIZATION NOTE(noIdentitySelectedNotification): Whitespace at eol

Thanks. Updated patch with the nit fixed. I'm requesting beta approval just in case there will be a b3 for TB58.

Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/bc64c9f2d525 Allow enforcing email based scheduling instead of server-side scheduling on caldav servers - processing part. r=philipp https://hg.mozilla.org/comm-central/rev/87048847b0a3 Enable enforcing of email based scheduling if caldav servers advertise auto-scheduling capability - UI part. r=philipp

Beta (TB 58, Calendar 6.0): https://hg.mozilla.org/releases/comm-beta/rev/48795dfca3c6 https://hg.mozilla.org/releases/comm-beta/rev/bfdaff2607e4 I landed that based on the approval but it has plenty of string changes. Would you like me to back it out again?

Ah yes, the string changes, thanks for brinigng that up. MakeMyDay, what do you propose?

We need test coverage by real users for this feature since we cannot realy test this well with our existing test automation for all the different servers out there. I think some additional weeks on a channel with a relevant population outweighs the not translated strings on 58, if the fallback to en-us strings in case of not available localized strings still work (which I assume is the case).

The fallback works, but the standard process for strings on beta is the late-l10n flag, along with a post on m.d.l10n.

Thanks for the replies. Either way, we'll have a TB 59 beta with Calendar 6.1 in about two weeks, so the issue isn't big either way. I'm just hoping that we won't get into trouble with the l10n folks whose alarm bells might be ringing if they see new strings in a beta.

I have added a how-to for the feature to sumo: https://support.mozilla.org/en-US/kb/enable-email-invitations-caldav-servers-configured

Reporter and anybody interested in this feature: once TB58beta3 is available [1], please give this feature a shot with your CalDAV server. As always, please make sure you have backuped up your profile before moving to beta. A description how to use it is linked in comment 48 (available once the article is reviewed). If you have question/problems about installing/using TB beta not related to this feature, please use the regular support channels and don't ask in this bug. If you can confirm that is is working for you and it isn't confirmed to work for your server before, please drop a short note here including information for which server (and version) it is working. If you encounter any issue, please file a new bug blocking this one and include the above mentioned information. [1] https://www.mozilla.org/en-US/thunderbird/channel/

I've noticed today that email notifications are broken. My Caldav server backend is Microsoft-Exchange+Davmail. Since the Thunderbird version 58 beta 3 was released on January 7th, 2018, the cause of my bug may be this change on this release (see https://www.mozilla.org/en-US/thunderbird/58.0beta/releasenotes/). How to activate the new UI in the property dialog, as shown in https://support.mozilla.org/en-US/kb/enable-email-invitations-caldav-servers-configured?

What's described in the sumo link should be available without furthur action for caldav calendars in that version. Can you check the error console and also try witg all addons but Lightning disabled? If you encounter any issue, please file a new bug as requested in comment 49 with refetence to this bug and the used caldav server.

Thanks for your answer. Unfortunately, I don't see this feature. The release notes of 58.0beta says it should be there ("Calendar: Allow email scheduling for CalDAV servers supporting server-side scheduling") However, the Sumo page says "Starting with Thunderbird 59beta / Lightning 6.1". It seems that Sumo is right, and the release not is wrong. Correct?

No, the relnote is correct, it available since TB58b3 (but not localized in that release). Do you get any error messages in the console when opening the calendar properties? Do you use en-us?

I have TB58b3, Lightning 6.0b1, en-US. I confirm that the new UI described here with screenshots in SUMO is not in the calendar property dialog.

According to previous comment the feature is available since Thunderbird TB58b3, i.e. since Lightning 6.0b3. But you are using Lightning 6.0b1. Maybe you can download and retest with 6.0b3? https://archive.mozilla.org/pub/calendar/lightning/candidates/6.0b3-candidates/build1/

Lightning 6.0b3 is the solution, thanks a lot Stefan, the calendar property dialog contains the new option.

I hit a bug in this cool new feature, see https://bugzilla.mozilla.org/show_bug.cgi?id=1436949