Closed Bug 453145 Opened 16 years ago Closed 15 years ago
Using ctrl+s or 'Save' from menu in event dialog while editing a occurrence of a recurring event changes whole series
Using ctrl+s in event dialog while editing a single occurrence of a recurring event saves changes to whole recurring event and changes recurrence pattern (in a way I couldn't identify until now, but depending on the occurrence you modified). You see those unintentional changes immediately when using ctrl+s more than once. STR: ==== 1. Create a recurring event (e.g. every other day, three times). 2. Open single occurrence of event you want to modify. 3. Change title or end time. 4a. Hit ctrl+s two times. 4b. Hit ctrl+s one time and close dialog.
Confirmed using Lightning 1.0pre (20081003) with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20081003 Shredder/3.0b1pre.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Issue can be reproduced in Sunbird 0.8 (2008091720) too. It seems that the second Save command shifts the start date of the whole recurrence rule to the date of the edited occurrence. Therefore all other occurrences are moved to a new date.
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
Martin, can you look into this bug?
Assignee: nobody → mschroeder
Summary: Using ctrl+s in event dialog while editing a occurrence of a recurring event changes whole series → Using ctrl+s or 'Save' from menu in event dialog while editing a occurrence of a recurring event changes whole series
First result: On the first save, the listener, which is passed to the callback, returns the parent item with incremented X-MOZ-GENERATION and _not_ the created/modified exception item.
The modifyItem function for different calendar providers use following pattern where aNewItem is the modified item (the exception) passed in. var modifiedItem = aNewItem.parentItem.clone(); this.notifyOperationComplete(aListener, Components.results.NS_OK, Components.interfaces.calIOperationListener.MODIFY, modifiedItem.id, modifiedItem); So, we get back the parentItem.
This is a workaround patch to fix this bug for now, the real work needs to be done in bug 396182.
Attachment #384368 - Flags: review?(mschroeder)
Comment on attachment 384368 [details] [diff] [review] Fix - v1 r=mschroeder, but please mark it as a workaround, and add a reference to the underlying issue.
Attachment #384368 - Flags: review?(mschroeder) → review+
(In reply to comment #7) > (From update of attachment 384368 [details] [diff] [review]) > r=mschroeder, but please mark it as a workaround, and add a reference to the > underlying issue. Done. Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/e08745a3f275> -> FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20100305 Calendar/1.0b2pre
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.