287985 - Can't save task start or due dates.

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: 20050320 + bug286228 patch

task dialog is not updated for new interfaces


Reproducible: Always

Steps to Reproduce:
1. New Task
2. add title
3. click checkbox for start or due date
4. click ok
5. edit same task
Actual Results:  
New task produces a task dialog where the start date is blank and the javascript
console says:

  Error: event.startDate has no properties
  Source File: chrome://calendar/content/eventDialog.js
  Line: 162

task appears in todo list with no start date.
editing same task shows task with no date (checkbox not clicked)

Expected Results:  
task appears in todo list with given start date.
editing same task shows checkbox still clicked and has same date.

Comment 1

[gekacheka]

Attachment: eventDialog.js patch to use todo.entryDate, date.valid (checked in)

(patch -p 2 -l -i file.patch)

when event bound to a task (calIToDo),

uses event.entryDate instead of event.startDate .
http://lxr.mozilla.org/seamonkey/source/calendar/base/public/calITodo.idl#54

uses event.entryDate.valid instead of event.entryDate.isSet .
http://lxr.mozilla.org/seamonkey/source/calendar/base/public/calIDateTime.idl#57


Also fixes a few calls to getElementValue with the wrong property name.


The result of this patch sets the dates in the todo object (when instrumented
after dates are set), but the dates are not ultimately saved (does not display
dates in task list, and editing task again shows task with checkboxes
unchecked).  

I.e., this patch addresses in dialog, but there remain problems in storage.

Comment 2

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

Comment on attachment 178769 [details] [diff] [review]
eventDialog.js patch to use todo.entryDate, date.valid (checked in)

checked in this patch. Not closing bug yet, for the reasons noted in the end of
comment 1

Comment 3

[gekacheka]

Mysterious.

value seems to be lost at 
http://lxr.mozilla.org/seamonkey/source/calendar/providers/storage/calStorageCalendar.js#769
768         } else if (row.item_type == CAL_ITEM_TYPE_TODO) {
769             item.entryDate = newDateTime(row.todo_entry);
770             item.dueDate = newDateTime(row.todo_due);
771             item.completedDate = newDateTime(row.todo_complete);
772             item.percentComplete = row.todo_complete;
773         }

Instrumenting this code as follows
        } else if (row.item_type == CAL_ITEM_TYPE_TODO) {
            item.entryDate = newDateTime(row.todo_entry);
            item.dueDate = newDateTime(row.todo_due);
            item.completedDate = newDateTime(row.todo_completed); // note final 'd'
            item.percentComplete = 77; // test value, was row.todo_complete;

            var JSCONSOLE = Components.classes["@mozilla.org/consoleservice;1"]
                          .getService(Components.interfaces.nsIConsoleService);
            function jsLog(string) {
              JSCONSOLE.logStringMessage(string);
            }
            jsLog("row.title="+row.title+"\n"+
                  "row.todo_entry="+newDateTime(row.todo_entry)+",
row.todo_due="+newDateTime(row.todo_due)+"\n"+
                  "item.entryDate="+item.entryDate+",
item.dueDate="+item.dueDate+"\n"+
                  "i.w.mEntryDate="+item.wrappedJSObject.mEntryDate+",
i.w.mDueDate="+item.wrappedJSObject.mDueDate+"\n"+
                  "item.isMutable="+item.isMutable+",
item.percentComplete="+item.percentComplete);
        }


produces the following

row.title=start & due
row.todo_entry=2005/03/29 17:00:00 UTC, row.todo_due=2005/03/30 16:00:00 UTC
item.entryDate=0000/01/00 00:00:00, item.dueDate=0000/01/00 00:00:00
i.w.mEntryDate=0000/01/00 00:00:00, i.w.mDueDate=0000/01/00 00:00:00
item.isMutable=true, item.percentComplete=77

Setting the todo date properties doesn't seem to be working, though setting the
percent complete property does.  Setting the date property works fine for events
just a few lines above.

Comment 4

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

The problem is that calITodo.idl specifies the start and end date as readonly.
The same attributes in calIEvent are not readonly. I wonder why. And i wonder
why trying to set it anyway doesn't throw an error.

Comment 5

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

Attachment: make attributes readwrite (checked in)

the obvious patch to make the attributes not readonly.

Comment 6

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

Comment on attachment 179096 [details] [diff] [review]
make attributes readwrite (checked in)

Er, r=me for the calITodo changes at the end of this patch, but you've included
a lot of Sync and other bits in here as well...

Comment 7

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

Comment on attachment 179096 [details] [diff] [review]
make attributes readwrite (checked in)

whoops, i shouldn't just use cat to check a diff, without scrolling up.
anyway, checked in the calITodo.idl part. But somehow, i still can't edit the
date of a todo. It works in a xpcshell testcase though, so there is some
improvement.

Comment 8

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

Attachment: set .valid

It almost works. Only .valid on the todo isn't set correctly (at least not from
the storage provider). This patch fixes that.

Comment 9

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

Comment on attachment 182205 [details] [diff] [review]
set .valid

I'm actually working on fixing SetTimeInTimezone, but I didn't catch this bug;
r=me :)

Comment 10

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

patch checked in. All should work now.