453145 - Using ctrl+s or 'Save' from menu in event dialog while editing a occurrence of a recurring event changes whole series

Status: VERIFIED FIXED

(Calendar :: General, defect)

Description

[Martin Schröder [:mschroeder]]

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.

Comment 1

[Stefan Sitter [:ssitter]]

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.

Comment 2

[Stefan Sitter [:ssitter]]

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.

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

Martin, can you look into this bug?

Comment 4

[Martin Schröder [:mschroeder]]

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.

Comment 5

[Martin Schröder [:mschroeder]]

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.

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Fix - v1

This is a workaround patch to fix this bug for now, the real work needs to be done in bug 396182.

Comment 7

[Martin Schröder [: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.

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

(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

Comment 9

[Damian Szczepanik]

verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100305 Calendar/1.0b2pre

Comment 10

[Philipp Kewisch [:Fallen][📱📆]]

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".