Closed Bug 709604 Opened 13 years ago Closed 10 years ago

Updated invitations in Thunderbird/Lightning are not sent out

Categories

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

Lightning 1.0
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 938459

People

(Reporter: davidhowdon, Unassigned)

References

Details

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

Steps to reproduce:

In Thunderbird 8.0 with Lightning 1.0 I edited an appointment which contained invitations to someone who should be notified by email (in an Outlook compatible format) and who had received an invitation when the appointment was set up.


Actual results:

The appointment was edited in my calendar but no notification to the invitee was sent.


Expected results:

A notification should have been sent to the invitees updating the appointment.
Hi David,
What type of calendar is this event in? 
Please enable calendar.debug.log and calendar.debug.log.verbose in the advanced config editor, repeat the modification and check for error console messages.
Caméléon,

Not sure what types of calendar there are.  It is in the sort of calendar you get with Thunderbird 8.0 and Lightning 1.0, there only seems to be one type.

Error log contents (no idea which ones are relevant)

Could not read chrome manifest file 'C:\Users\David Howdon\AppData\Roaming\Thunderbird\Profiles\q33zl44g.default\extensions\en-GB@dictionaries.addons.mozilla.org\chrome.manifest'.

sendItems: Sending Email...

sendXpcomMail: Found USER autoResponse type.
This type is currently unsupported, the compose API will always enter a text/plain
or text/html part as first part of the message.
This will disable OL (up to 2003) to consume the mail as an iTIP invitation showing
the usual calendar buttons.

sendXpcomMail: Found AUTO autoResponse type.

mail text:
MIME-version: 1.0
From: [[my email address removed]]
To: [[recipient email address removed]]
Date: Sun, 15 Jan 2012 22:37:06 GMT
Subject: Event Invitation: Test event (ignore)
Content-class: urn:content-classes:calendarmessage
Content-type: text/calendar; method=REQUEST; charset=UTF-8
Content-transfer-encoding: 8BIT

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20120115T223638Z
LAST-MODIFIED:20120115T223704Z
DTSTAMP:20120115T223704Z
UID:752ab084-aaea-45d9-9fc4-0559c681f77b
SUMMARY:Test event (ignore)
ORGANIZER;RSVP=TRUE;CN=David Howdon;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:[[my email address removed]]
ATTENDEE;RSVP=TRUE;CN=David Howdon;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
 ANT:mailto:[[recipient email addres removed]]
DTSTART;TZID=Europe/London:20120123T200000
DTEND;TZID=Europe/London:20120123T210000
LOCATION:Nowhere
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

_createTempImipFile path: C:\Users\DAVIDH~1\AppData\Local\Temp\itipTemp

sendItems: Sending Email...

sendXpcomMail: Found USER autoResponse type.
This type is currently unsupported, the compose API will always enter a text/plain
or text/html part as first part of the message.
This will disable OL (up to 2003) to consume the mail as an iTIP invitation showing
the usual calendar buttons.
I can confirm that this is still a problem with Lightning 1.2.1 with Thunderbird 10.0.2 on WInXP SP3.

I can also confirm that this is not an issue with Lightning v0.9 and Thunderbird 2.0.0.24.
I can confirm the bug with TB 12.0.1 + lightning 1.4, under windows.

>>Important Information<<
While updating the event start/end time, using the dialog box, the bug occurs : no updated invitation sent!
On main lightning tab, if you slide the event, then the invitation update is sent!
This behavior is 100% reproducible.
If you copy/paste the event, the update of invitation is fine (cancella)
I can confirm the bug with TB 12.0.1 + lightning 1.4, under windows.

>>Important Information<<
While updating the event start/end time, using the dialog box, the bug occurs : no updated invitation sent!
On main lightning tab, if you slide the event, then the invitation update is sent!
This behavior is 100% reproducible.
If you copy/paste the event, the update of invitation is fine (cancellation then  invation).

Updating the event title, location, category, set an alarm does not send an alarm, add an attendees (see BUG#716373) does not send an invitation!

All tests here done on a local agenda.

This is a really annoying bug.
I can confirm the bug with TB 12.0.1 + lightning 1.4, under windows.

>>Important Information<<
While updating the event start/end time, using the dialog box, the bug occurs : no updated invitation sent!
On main lightning tab, if you slide the event, then the invitation update is sent!
This behavior is 100% reproducible.
If you copy/paste the event, the update of invitation is fine (cancellation then  invation).

Updating the event title, location, category, set an alarm does not send an alarm, add an attendees (see BUG#716373) does not send an invitation!

All tests here done on a local agenda. Tests performed on windows only. Not tested under linux yet. I could test it on Fedora 16 w/ up to date TB/LGHTNG is required.

This is a really annoying bug.
Applicable to lightning 1.5 too. (TB 13.0)
Guess what ... Applicable to lightning 1.6 too. (TB 14.0)
Still applicable on lightning 1.7 too. (TB 15.0)... what is missing for confirming this bug?
Still applicable on lightning 1.9.1 too. (TB 17.0.6).
Again, what is missing for confirming/assigning this bug?
Also experiencing this with Lightning 1.9.1 / TB 17.0.7
It sounds like this bug is bugging a lot of people. Why is it still unconfirmed and unassigned? Did all the developers get iDevices and switch to iCal?
sorry, I don't have the time to look at this for the moment. Hope Wayne can help here and maybe confirm the bug...
perhaps baffoni@aerovironment.com  or  buecher can advise

(I don't actually use calendar)
Flags: needinfo?(buecher)
Flags: needinfo?(baffoni)
Thanks for these comments  fred_g_bdx  as they do at least provide me with a work around for the problem
This bug very much still exisits, so does the workaround.
Confirmed on Win7 / Tbird 17.0.x / Lightning 1.9.1
Confirmed on Ubuntu 13.04 amd64 / Tbird 17.0.x / Lightning 1.9.1

>>> IMPORTANT <<<
However, testing on Ubuntu 12.04 amd64 / Tbird 23.0 (from beta repository) / Lightning 2.5b2 (from Mozilla server) reveals that I can indeed drag appointments along and the updates are sent out. Opening and changing the event (the workaround) works correctly as before.

cheers
Tom
This bug very much still exisits, so does the workaround.
Confirmed on Win7 / Tbird 17.0.8 / Lightning 1.9.1
Confirmed on Win XP / Tbird 17.0.8 / Lightning 1.9.1
Is there any solution planed?
Why is this bug "UNCONFIRMED"? Recent Thunderbid/Lightning builds are still affacted.
Confirmed on Win7 (Local Calendars) / Tbird 24.0 / Lightning 2.6.
Workaround?
Flags: needinfo?(baffoni)
Confirmed on WinXP / Thunderbird 24.2.0 / Lightning 2.6.4

I found the following workaround:

When you are done editing the appointment, use "Save" (Ctrl+S) from the menu or use the keyboard shortcut. Then close the window manually.

Do not use "Save and close", neither the icon nor from the menu or shortcut. It will not ask you to send emails :(

I don't get why this bug is still "UNCONFIRMED", also the fix should be easy (as it is working with save already).
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(buecher)
IF you are finding this post and have Thunderbird 24.4 and Lightning 2.6.4 . Issue is targeted to be fixed in 2.6.5 see #938459 mentioned above.

Workaround:
2. [Working] close the dialog by hiiting the (x) after modifying a major prop of the same event and confirm saving the item
You need to log in before you can comment on or make changes to this bug.