Closed Bug 994200 Opened 10 years ago Closed 10 years ago

Changing calendar in event dialog may cause an inappropriate organizer/attendee set

Categories

(Calendar :: Dialogs, defect)

Lightning 2.6.4
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: MakeMyDay, Assigned: MakeMyDay)

Details

(Keywords: regression)

Attachments

(1 file)

STR:
1. have 3 calendars, two local, one calDAV - each with different organizer 
   id's set
2. add a new event with attendees to local calendar A and complete with 
   save&close
3. reopen the event and try to
 a. change the calendar to local calendar B
 b. change the calendar calDAV calendar C
4. open attendee dialog and see who is in the list
5. cancel attendee dialog but not the event dialog
6. change the calendar back to calendar A
7. open attendee dialog and again see who is in the list

Result:
4 (with 3a): Event has the organizer from calendar A
4 (with 3b): Event has the organizer from calendar C
7 (with 3a): Event still has the organizer from calendar A
7 (with 3b): Event still has the organizer from calendar C

Expected:
4 (with 3a): Event has the organizer from calendar B
4 (with 3a): Event has the organizer from calendar C
7 (both): Event has the organizer from calendar A

This is a problem within updateCalendar() in calendar-event-dialog.js and a regression from bug 735619 and bug 723610. The check on calendar.aclEntry will return false on local calendars which prevents organizer updates if the target calendar is a local one (leads to 4 (3a) and 7). Further more, the calendar.id != item.calendar.id check return always false if you change the calendar back to the original one without saving inbetween. If the organizer was changed meanwhile sucessfully, you now have a wrong one -> 7 (3a).

The calendar.aclEntry check should be either removed or replaced by a complete ACL check like when filling the calendar list. I guess it probably can be removed safely here, because there is already done an ACL check when filling the calendar list, so we can assume to have an accessible calendar. To resolve the second issue and prevent unintended changing of the organizer without a user triggered calendar change, we need to check against the previously selected calendar and not the one set on load.
Patch with suggested fixes.
Attachment #8404117 - Flags: review?(philipp)
Comment on attachment 8404117 [details] [diff] [review]
OrganizerNotAlwaysUpdatedOnCalendarChangeInEventDialog-V1.diff

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

Looks good to me, r=philipp
Attachment #8404117 - Flags: review?(philipp) → review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/80f09b08cbd2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
OS: Windows 7 → All
Hardware: x86_64 → All
Target Milestone: --- → 3.3
Attachment #8404117 - Flags: approval-calendar-release?(philipp)
Attachment #8404117 - Flags: approval-calendar-beta?(philipp)
Attachment #8404117 - Flags: approval-calendar-aurora?(philipp)
Attachment #8404117 - Flags: approval-calendar-release?(philipp)
Attachment #8404117 - Flags: approval-calendar-release+
Attachment #8404117 - Flags: approval-calendar-beta?(philipp)
Attachment #8404117 - Flags: approval-calendar-beta+
Attachment #8404117 - Flags: approval-calendar-aurora?(philipp)
Attachment #8404117 - Flags: approval-calendar-aurora+
https://hg.mozilla.org/releases/comm-aurora/rev/23abaf03b0b6
https://hg.mozilla.org/releases/comm-esr24/rev/83644ae8e82b

Per discussion with Standard8, there's really no point in pushing to comm-beta at this point in the release cycle, so I only pushed to Aurora/ESR24.
Keywords: checkin-needed
Target Milestone: 3.3 → 2.6.5
You need to log in before you can comment on or make changes to this bug.