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

VERIFIED FIXED in 1.0b1

Status

VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: bv1578, Assigned: Fallen)

Tracking

({regression})

unspecified
1.0b1
regression
Bug Flags:
blocking-calendar1.0 +

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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

10 years ago
Bug is also reproducible on linux and Mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
(Reporter)

Comment 2

10 years ago
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

10 years ago
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
Flags: blocking-calendar1.0?
Keywords: regression
(Assignee)

Updated

10 years ago
Flags: blocking-calendar1.0? → blocking-calendar1.0+
(Assignee)

Comment 4

10 years ago
Created attachment 358022 [details] [diff] [review]
Fix - v1

addDuration doesn't return anything. This patch fixes and also some indentation and a problem when converting items.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #358022 - Flags: review?(Berend.Cornelius)
(Assignee)

Updated

10 years ago
Depends on: 416138
Whiteboard: [needs review]

Comment 5

10 years ago
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.
Attachment #358022 - Flags: review?(Berend.Cornelius) → review+
(Assignee)

Comment 6

10 years ago
(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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
(Assignee)

Updated

10 years ago
Whiteboard: [needs review]

Comment 7

10 years ago
Checked with lightning and sunbird build 20090126 -> VERIFIED.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

9 years ago
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.