Closed Bug 1238381 Opened 8 years ago Closed 8 years ago

Declining of invitation does not work

Categories

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

Lightning 4.0.5
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: MakeMyDay, Assigned: MakeMyDay)

References

Details

Attachments

(1 file)

From bug 1229329 comment 19:

I just tested the patch https://hg.mozilla.org/comm-central/rev/4dc92595235c
against lightning 4.0.4.1 and would like to remark, that it has some site effect.
While the dialog with the question whether to inform the owner via email when adding or modifying the event appears  fine, it does not come up anymore when event is deleted from calendar.

Steps to reproduce:
1) Add an invitation to (see dialog comes up)
2) delete the invitation (no dialog comes up)

Position in code:

Removing line 601 in calItipUtils.jsm
invitedAttendee = invitedAttendee.clone();
causes that bug. Part of the section "in case the attendee has just deleted the item"

@spuch: can you please confirm that this is an issue for you in Lightning 4.0.5 or 4.0.5.1 (this versions are not on AMO but distributed with the latetest TB updates to 38.5.0/38.5.1)?
Summary: Declining of invation does not work → Declining of invitation does not work
Attached patch FixDecliningInvitation-V1.diff — — Splinter Review
Possible patch reverting the calItipUtils changes from bug 1229329.

I'll wait for feeback from spuch before requesting review for this.
Flags: needinfo?(s.puch)
(In reply to MakeMyDay from comment #0)
> @spuch: can you please confirm that this is an issue for you in Lightning
> 4.0.5 or 4.0.5.1 (this versions are not on AMO but distributed with the
> latetest TB updates to 38.5.0/38.5.1)?
Wasn't easy to get that version of lightning installed. The update of TB 38.4.0 to TB 38.5.0 just removed old Lightning version so that I hat to install it again from AMO.
Tomorrow morning I had the same problem again: When updating from TB 38.5.0 to 38.5.1 Lightning 4.0.4.1 was removed, but no new version was installed....
Downloading the full TB Installed for a complete new installation didn't help either, so I hat to extract the Lightning directory manually from the TB installer!
Finally I've got TB 38.5.1 and Lightning 4.0.5.1 (OS: Win7 x64) up and running and I can confirm that issue: When deleting an event no dialog comes up.

After applying the patch from Comment 1 (which reverts the previous changes to calItipUtils) the dialog works again. I tested adding an event to calendar, modifying an event using right context menu (I participate eventually, I confirm later, etc.) and deleting an event. In every case the dialog come up as expected.

IMHO this patch can be reviewed. Thanks!
Flags: needinfo?(s.puch)
Attachment #8706143 - Flags: review?(philipp)
Attachment #8706143 - Flags: approval-calendar-release?(philipp)
Attachment #8706143 - Flags: approval-calendar-beta?(philipp)
Attachment #8706143 - Flags: approval-calendar-aurora?(philipp)
Assignee: nobody → makemyday
Status: NEW → ASSIGNED
Comment on attachment 8706143 [details] [diff] [review]
FixDecliningInvitation-V1.diff

Review of attachment 8706143 [details] [diff] [review]:
-----------------------------------------------------------------

Why does this fix it, and why is it a problem to clone the attendee earlier?
I'm not sure, because I don't exactly know what the clone function does internally and I'm no coding expert. Does clone chance anything (internal ID or something)?

In Line 601 the "invitedAttendee" is saved as "origInvitedAttendee". When you clone the attendee earlier
"origInvitedAttendee" will become a cloned original while cloning later means first to really save the original and clone after that.

In line 609 and 610 the "origInvitedAttendee.participationStatus" and the "invitedAttendee.participationStatus" are compared in order to decide if a REPLY should be sent. Obviously there must be a difference between saving the original before or after cloning.
OK, I think I got it.
Cloning first means, after line 601 "origInvitedAttendee" and "invitedAttendee" are the same obects and their attributes are compaired in line 609 and 610 (which are always the same). Cloning after line 601 means that in line 609 and 610 two different objects are compaired while one (the cloned) has got a modified attribute from 604.
And comment on that?
Attachment #8706143 - Flags: review?(philipp)
Attachment #8706143 - Flags: review+
Attachment #8706143 - Flags: approval-calendar-release?(philipp)
Attachment #8706143 - Flags: approval-calendar-release+
Attachment #8706143 - Flags: approval-calendar-beta?(philipp)
Attachment #8706143 - Flags: approval-calendar-beta+
Attachment #8706143 - Flags: approval-calendar-aurora?(philipp)
Attachment #8706143 - Flags: approval-calendar-aurora+
https://hg.mozilla.org/comm-central/rev/39fc24a49db1
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.8
https://hg.mozilla.org/releases/comm-aurora/rev/2b8e1bd4f8ec
Target Milestone: 4.8 → 4.7
https://hg.mozilla.org/releases/comm-beta/rev/edcecc72bbb2
Target Milestone: 4.7 → 4.6
https://hg.mozilla.org/releases/comm-esr38/rev/e31024e89db1
Target Milestone: 4.6 → 4.0.6
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: