469146 - Drag and drop tasks in month and multiweek views, doesn't change tasks' due date.

Status: VERIFIED FIXED

(Calendar :: Tasks, defect)

Description

[Decathlon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Lightning/1.0pre Shredder/3.0b2pre

Dragging a task to move it to another day causes a change in his duration time because its due date doesn't change at all.

Reproducible: Always

Steps to Reproduce:
1. create a new task with start date and due date;
2. turn view to multiweek-view or month-view and set "Show Tasks in Calendar" from View menu;
3. drag and drop the task to a previous day (if task's period is more than one day, drag the first element or another to a previous free day).

Actual Results:  
The start date is changed to the day where you drop the task, but the due date is the same. In the view now you can see a task that starts from the new day to the original end date, so task's duration is changed.


Expected Results:  
The task should change start date and due date but his duration shouldn't change.


If you drag the task to a day in the future, you get a valid task with end date that occurs before the start date (it isn't showed in the calendar view but is still in task list).

Comment 1

[Andreas Treumann]

Bug is also reproducible on linux and Mac.

Comment 2

[Decathlon]

In calendar-widgets.xml file, newItem.dueDate is always a null value after onDropItem() is called

  let newItem = this.onDropItem(item, session).clone();
  let newStart = newItem.startDate || newItem.entryDate;
  let newEnd = newItem.endDate || newItem.dueDate;

Probably due to patch 350759 in bug 416138. I posted a comment there.

Comment 3

[Andreas Treumann]

Drag&drop of events in month/multiweek view changes the duration to zero.

STR:

- create an event with default duration of 1 hour
- drag&drop this event to the next day
- after this the end time of this event is the start time

Comment 4

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

Attachment: Fix - v1

addDuration doesn't return anything. This patch fixes and also some indentation and a problem when converting items.

Comment 5

[Berend Cornelius]

Comment on attachment 358022 [details] [diff] [review]
Fix - v1

>+                let newEnd = start.clone();
>+                start.addDuration(oldDuration);
>+                newItem[calGetEndDateProp(newItem)] = newEnd;

Here you add add a duration to the startDate. Consequently the duration of the new item is always zero.
The rest looks very good
r=berend.

Comment 6

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

(In reply to comment #5)
> (From update of attachment 358022 [details] [diff] [review])
> >+                let newEnd = start.clone();
> >+                start.addDuration(oldDuration);
> >+                newItem[calGetEndDateProp(newItem)] = newEnd;
> 
> Here you add add a duration to the startDate. Consequently the duration of the
> new item is always zero.
Good catch, changed.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/316062c8d4af>

-> FIXED

Comment 7

[Andreas Treumann]

Checked with lightning and sunbird build 20090126 -> VERIFIED.