307137 - Task startdate, duedate, category, percentComplete columns empty

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Joey Minta]

None of these columns have been updated to use the new event properties.

Comment 1

[Joey Minta]

Attachment: use new properties

Pretty straightforward.  I converted compareDate to use calDateTimes also.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 194941 [details] [diff] [review]
use new properties

> function compareDate(a, b) {
...
>-  return ((a < b) ? -1 :      // avoid underflow problems of subtraction
>-          (a > b) ?  1 : 0); 
>+  return ((a.compare(b)) > 0); 

The funtion used to return -1,0 or 1. You made it return true or false. Is that
the right thing to do?

Comment 3

[Joey Minta]

Attachment: v2

Better compareDate function.  Returns 1,0,-1 and handles the case where the
date isn't set.

Comment 4

[Joey Minta]

Patch checked in

Comment 5

[gekacheka]

Comment on attachment 194944 [details] [diff] [review]
v2

This patch causes regression: undated tasks should sort to today, not as
infinitely in the future.

Comment 6

[Joey Minta]

(In reply to comment #5)
> (From update of attachment 194944 [details] [diff] [review] [edit])
> This patch causes regression: undated tasks should sort to today, not as
> infinitely in the future.
> 

I disagree that the previous behavior was correct.
1.) Intuitively, I would never expect an item which did not possess a property
to be sorted in between two items which did.
2.) The same sort on the same task list should always produce the same results.
If 'today' also factors in to the sort, this will not be the case.

Comment 7

[gekacheka]

Undated tasks are ones that could be done now if the user has some free time. 
It is ok if they are not done today, and they will appear again tomorrow with
tomorrow's tasks.

Dated tasks are ones that should be done on or by a specific date, and often it
doesn't make sense to do them earlier.  For example, paying monthly bills.  
Weekly chores.  An assignment that can't be started until after more details are
settled at the next meeting, but you know you need to reserve time for.
  
If the user has many tasks with future dates that are weeks, months, or years in
advance, then the undated tasks that could be done today appear AFTER them (far
in the future) instead of being sorted with today's tasks.


(It sometimes helps to look at the bug that added code.  In this case, looking
at CSV blame for unifinderToDo.js
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/calendar/resources/content/unifinderToDo.js&rev=1.85#505
says this was added in bug 220075, where bug 220075 comment 3 says

  RFC2445,sec4.6.2 says

     A "VTODO" calendar component without the "DTSTART" and "DUE" (or
     "DURATION") properties specifies a to-do that will be associated with
     each successive calendar date, until it is completed.

  So undated todos should appear sorted with today's todos when sorted by 
  start or due date.
)

Comment 8

[Joey Minta]

Attachment: change sort pattern

makes missing dates be today.

I don't still don't like it.  The way I read the RFC, it only tells us not to
filter out the task if there's a date-range.  The tasklist isn't a filter. 
However, mvl pointed out that consistency with 0.2 is probably the best option
until we figure out a better solution.

Comment 9

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 195027 [details] [diff] [review]
change sort pattern

the today() function should be named now(), because it also returns the time
part.
r=mvl with that changed.

Comment 10

[Joey Minta]

Comment on attachment 195027 [details] [diff] [review]
change sort pattern

Patch checked in.

Comment 11

[gekacheka]

Comment on attachment 195027 [details] [diff] [review]
change sort pattern

Performance regression:  Allocating date objects in the compare function
significantly slows down the sort (especially with hundreds of items), and it
also means the sort is not stable ('now' changes over time in a long sort).

I suggest doing as the original did, which is to compute 'now' once just before
the beginning of the sort, and reuse that date for the comparing undated tasks
during that sort.

Comment 12

[Joey Minta]

Attachment: fix

Additional patch (based on current cvs state) to fix gekacheka's new comments.

what a mess...

Comment 13

[Joey Minta]

Comment on attachment 195167 [details] [diff] [review]
fix

Patch checked in

Comment 14

[Alain Knaff]

While I can understand comment #7's viewpoint, many people just want the opposite behavior: treat tasks with due dates as a higher priority than those without (just consider the number of reports about this).

Also, the argument about paying bills which have not yet been received is flawed. That's why tasks have a _start_ date, which means that they cannot be started before that date.

So, shouldn't the sort behavior be user-configurable somewhere? Some want "no due date = today", but others prefer "no due date = +infinity"