Saving NEW Event/Task creates a new event each time

RESOLVED FIXED in 1.0b2

Status

Calendar
Internal Components
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: Sven, Assigned: Fallen)

Tracking

unspecified
1.0b2

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110306 Calendar/0.6a1

Saving a new Event or Task before using "Save and Close" creates a new Event/Task each time you save the it.

Reproducible: Always

Steps to Reproduce:
1. Push the New Task button in the toolbar.
2. Push File->Save or Ctrl+S in the new task window.
2.1 This creates the new Task.
3. Push File->Save or Ctrl+S again.
3.1 This creates another new task.
Actual Results:  
Saving creates serveral new tasks/events.

Expected Results:  
Saving should create ONE new task/events while saving the first time and then edit the new event.

Comment 1

11 years ago
Confirmed also with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9pre) Gecko/20071103 Calendar/0.8pre
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

11 years ago
Flags: blocking-calendar0.8?

Comment 2

11 years ago
Changing request flag into wanted. It can also be reproduced with 0.7
Flags: blocking-calendar0.8? → wanted-calendar0.8?

Comment 3

11 years ago
Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.
Flags: wanted-calendar0.8? → wanted-calendar0.8-
Duplicate of this bug: 420517

Comment 5

10 years ago
All items have equal values for CREATED and DTSTAMP. LAST-MODIFIED and UID are
different. 

Affected are events and items in all storage providers I tested: Storage DB,
local ICS file and Google Provider

Updated

10 years ago
Flags: wanted-calendar0.8- → wanted-calendar1.0?
(Assignee)

Comment 6

9 years ago
I tested this and it works for me, please reopen if the problem persists.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Reproducible using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090830 Lightning/1.0pre Shredder/3.0b4pre with STR from comment#0.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
(Assignee)

Comment 8

8 years ago
Created attachment 432530 [details] [diff] [review]
Fix - v1

This patch takes care. A new item doesn't have an id before it is saved, so the listener didn't save the item.

Something I noticed here: if the server does any server-side changes to a newly added item, then the event dialog will not be updated to these changes (i.e loadDialog is not called after save).

It would be quite simple to add a loadDialog call in the changed listener too, but this also means that if the user has a slow network connection and does more changes, they will probably be reverted when the item finally commits.

Definitely something to fix in a different bug, and I can imagine the solution will be quite ugly.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #432530 - Flags: review?(ssitter)
(Assignee)

Comment 9

8 years ago
Created attachment 432572 [details] [diff] [review]
Fix - v2

Forgot to qref
Attachment #432530 - Attachment is obsolete: true
Attachment #432572 - Flags: review?(ssitter)
Attachment #432530 - Flags: review?(ssitter)
Comment on attachment 432572 [details] [diff] [review]
Fix - v2

As often, the solution of one bug points to another:

Since we landed Bug 392021 in the meantime, the delete function has to be taken into account.

If I save the event and then press the delete button, the window closes, but the event is not deleted.

So the delete function also has to check if the Item has been saved in the meantime.

r- because of this
Attachment #432572 - Flags: review?(ssitter) → review-
(Assignee)

Comment 11

8 years ago
Created attachment 440173 [details] [diff] [review]
Fix - v1

Setting the mode to modify helps
Attachment #440173 - Flags: review?(Mozilla)
(Assignee)

Updated

8 years ago
Attachment #432572 - Attachment is obsolete: true
Comment on attachment 440173 [details] [diff] [review]
Fix - v1

looks good.
r=markus
Attachment #440173 - Flags: review?(Mozilla) → review+
(Assignee)

Comment 13

8 years ago
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/88a7728b9305>
-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
Flags: wanted-calendar1.0?
OS: Windows XP → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.