268167 - Saving task/todo with start date and no due date sets due date to start date

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2
Build Identifier: cvs-cal

Creating a new todo or saving an existing todo with a start date and no due date
sets the due date to the start date.

Reproducible: Always
Steps to Reproduce:
1. New Task
2. Add title
3. click start date checkbox (do not click due date checkbox)
4. click ok
5. view ics file of calendar where it is saved.

Actual Results:  
Task contains a DUE datetime (same as DTSTART datetime)

Expected Results:  
Task does not contain a DUE datetime

POSSIBLE DIAGNOSIS

Parsing a task with no due date from a hand edited ics file works, so
problem is only in storing the task.

I think the problem may be because oeICalToDo.AsICalComponent uses
oeICalEvent.AsICalComponent, which sets the end date if there is only
a start date.  (oeICalToDo uses oeICalEvent end date for its due date.)

Details:

In calendar.js, openToDoDialog is called by editNewToDo and editTodo
with call backs addToDoDialogResponse and modifyToDoDialogResponse.

 addToDoDialogResponse and modifyToDoDialogResponse call
 refreshRemoteCalendarAndRunFunction with functions "addTodo" and
 "modifyTodo". 

  refreshRemoteCalendarAndRunFunction runs the function as a method on
  gICalLib.

   gICalLib is initialized to an oeIICalContainer
   (by CalendarEventDataSource in calendarEvent.js)

    oeICalContainerImpl::addToDo calls oeICal.addTodo
    oeICalContainerImpl::modifyToDo calls oeICal.modifyToDo

     oeICal.addTodo and oeICal.modifyToDo call 
     calls oeICalTodo.AsIcalComponent

      oeICalTodo.AsICalComponent calls oeICalEvent.AsICalComponent

       oeICalEvent.AsICalComponent sets m_end to m_start if m_end is
       null and m_start is not null.

http://lxr.mozilla.org/mozilla/source/calendar/libxpical/oeICalEventImpl.cpp#2533
2533     //Create enddate if does not exist
2534     if( icaltime_is_null_time( m_end->m_datetime ) &&
!icaltime_is_null_time( m_start->m_datetime ) ) {
2535         //Set to the same as start date
2536         m_end->m_datetime = m_start->m_datetime;
2537     }

Comment 1

[gekacheka]

This bug is annoying because any ongoing task, that has no set due date and is
past its start date, is colored red after the due date is set to the start date.
 They should not be red because they are supposed to have no due date.  

A workaround is to set an explicit due date to some far future date on each such
task.

Comment 2

[Matthew (lilmatt) Willis]

Changing milestone to SB 0.3.
Since we're reworking events and tasks, we should see if this can be fixed in
the process.

CCing a bunch of people

Comment 3

[gekacheka]

Bug 274362 is about a related issue.  Currently the due date is an alias for the
end, and the duration is the difference between start and end.  But this means
it is impossible to schedule a task for a period that ends before the due date.
 So a fix for both may involve giving tasks a due date separate from the end date.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #3)
> Bug 274362 is about a related issue.  Currently the due date is an alias for the
> end, and the duration is the difference between start and end.  But this means
> it is impossible to schedule a task for a period that ends before the due date.
>  So a fix for both may involve giving tasks a due date separate from the end date.

This is all very different now.  The todo entry date and due date are completely
separate from the event start/end date; also, only events have a queryable
duration.  So this should, in theory, be fixed once todos are wired up on trunk.
 However, todos haven't been tested much, so there are probably some bugs there
still.

Comment 5

[Benjamin Hill]

Side effect - if you uncheck a due date, and close the item, the due date 
remains checked.

Comment 6

[Joey Minta]

Works for me on trunk.  gekacheka can you confirm?  (Bug 220075 works for me too).

Comment 7

[gekacheka]

libxpical has been replaced in back-end rewrite.  This is no longer a problem.
marking fixed.

(There are many regressions that prevent it from passing the tests in bug 220075
comment 27.)

Comment 8

[Marcia Knous [:marcia]]

Mass move of libxpical bugs to the Internal Components, per ctalbert.

Comment 9

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!