Closed Bug 469146 Opened 11 years ago Closed 11 years ago
Drag and drop tasks in month and multiweek views, doesn't change tasks' due date
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:22.214.171.124) 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).
Bug is also reproducible on linux and Mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
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.
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? → blocking-calendar1.0+
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)
Depends on: 416138
Whiteboard: [needs review]
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+
(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
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Checked with lightning and sunbird build 20090126 -> VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.