No email prepared when the timeslice of an event is changed from the calendar view

VERIFIED FIXED in 1.0b1

Status

Calendar
E-mail based Scheduling (iTIP/iMIP)
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: Wolfgang Sourdeau, Assigned: dbo)

Tracking

unspecified
1.0b1
Dependency tree / graph
Bug Flags:
wanted-calendar1.0 +

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-2)
Build Identifier: 0.8 rc1

When creating an event containing attendees. An email will be generated to notify them of changes. This feature does not happen when the event is modified directly on the calendar views. This was tested with weekly view but probably happens in other views as well.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Assignee)

Comment 1

10 years ago
Wolfgang, either dragging the event in week view or in-place editing its title opens up the Compose window to send out a new REQUEST for me (using storage calendar).
(Reporter)

Comment 2

10 years ago
I have retested it, in the weekview, using the latest nightly build. Both with CalDAV and a local calendar, same result.
When using the local calendar, a new event will not even generate a REQUEST email at tall.
No error show up in the console in that case. In CalDAV, some exceptions are triggered but our implementation might be the cause (although I would expect Lightning to be foolproof on that matter).

Comment 3

10 years ago
@Wolfgang: I try to reproduce this issue, but it works for me. Do you use a native Thunderbird version or Icedove?
(Reporter)

Comment 4

10 years ago
Icedove and Lightning do not use the same version of libstdc++ so I use Thunderbird for testing Lightning 0.8.

Comment 5

10 years ago
@Wolfgang: Now it's possible for me to reproduce your issue with a single event of a recurring rule. Could you confirm this scenario? Here are my 'Steps to reproduce:

STR:

- create a recurring event with attendees
- check the iMip/iTIP checkbox
- save the rule (compose window comes up)
- select a single event of this rule in the calendar view
- drag this event or use the grippies to change the start or end time

Result:

- it's not possible to change the start/end time
- the compose windows doesn't comes up.


Error console output:

Fehler: [Exception... "'Component not initialized' when calling method: [calIItipItem::getItemList]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/at93795/Application%20Data/Thunderbird/Profiles/bigaf98i.default2/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItipEmailTransport.js :: cietCTIF :: line 293"  data: no]
Quelldatei: file:///C:/Documents%20and%20Settings/at93795/Application%20Data/Thunderbird/Profiles/bigaf98i.default2/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItipEmailTransport.js
Zeile: 293

Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

10 years ago
OS: Linux → All
Hardware: PC → All
(Assignee)

Updated

10 years ago
Flags: wanted-calendar0.9+
(Reporter)

Comment 6

10 years ago
I confirm!
(Assignee)

Comment 7

10 years ago
Cause for this bug: the iTIP item is initialized with the icalString of a single instance of a recurring series (just a VEVENT with RECURRENCE-ID) which gets lost when parsed again using the ics parser in calItipItem.js.
There are a couple of related bugs, e.g. incoming iTIP requests: we still cannot cope with parent-less items resp. ics fragments that contain parent-less occurrences.
(Assignee)

Updated

9 years ago
Depends on: 457203
Flags: wanted-calendar0.9+ → wanted-calendar1.0+
(Assignee)

Updated

9 years ago
Depends on: 392465
(Assignee)

Comment 8

9 years ago
fixed with checkins on bug 392465 and bug 457203
Assignee: nobody → daniel.boelzle
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0

Comment 9

9 years ago
Checked with lightning build 20081130 -> VERIFIED.
Status: RESOLVED → VERIFIED
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.