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)
Tracking
(Not tracked)
RESOLVED
FIXED
2.6.5
People
(Reporter: MakeMyDay, Assigned: MakeMyDay)
Details
(Keywords: regression)
Attachments
(1 file)
2.26 KB,
patch
|
Fallen
:
review+
Fallen
:
approval-calendar-aurora+
Fallen
:
approval-calendar-beta+
Fallen
:
approval-calendar-esr+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•10 years ago
|
||
Patch with suggested fixes.
Attachment #8404117 -
Flags: review?(philipp)
Comment 2•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 3•10 years ago
|
||
https://hg.mozilla.org/comm-central/rev/80f09b08cbd2
Updated•10 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Target Milestone: --- → 3.3
Updated•10 years ago
|
Attachment #8404117 -
Flags: approval-calendar-release?(philipp)
Attachment #8404117 -
Flags: approval-calendar-beta?(philipp)
Attachment #8404117 -
Flags: approval-calendar-aurora?(philipp)
Updated•10 years ago
|
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+
Updated•10 years ago
|
Keywords: checkin-needed
Comment 4•10 years ago
|
||
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
Assignee | ||
Updated•10 years ago
|
Target Milestone: 3.3 → 2.6.5
You need to log in
before you can comment on or make changes to this bug.
Description
•