328216 - It is not possible to assign duration to a task

Status: RESOLVED FIXED

(Calendar :: Tasks, defect)

Description

[Flavia]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: Mozilla Sunbird/0.3a1

The iCalendar standard states that tasks (or to-dos) can contain a due date or a duration field (either of the two).
In Sunbird you can only assign a due date to a task, but never a duration.
So it does not follow the standard in this.

Reproducible: Always

Steps to Reproduce:
1. Create a new task

Comment 1

[Joey Minta]

> The iCalendar standard states that tasks (or to-dos) can contain a due date or
> a duration field (either of the two).
> In Sunbird you can only assign a due date to a task, but never a duration.
> So it does not follow the standard in this.

I'd like to point out that "following the standard" does not mean "offering UI for every option in the standard."  Some parts of RFC2445, like the full range of recurrence options, would be incredibly confusing to everyday-users.

Instead, Sunbird's goal is to *understand* all of the RFC, even if it doesn't let users exercise all of those options.  In this case, importing a to-do with a duration probably ought to be converted to a due-date.  If this already works, then I'd argue that this bug should be closed.  If it does not, please attach a testcase ics file that contains such a todo, so that the developers can work on addressing this issue.

Comment 2

[Flavia]

(In reply to comment #1)
> Instead, Sunbird's goal is to *understand* all of the RFC, even if it doesn't
> let users exercise all of those options.  In this case, importing a to-do with
> a duration probably ought to be converted to a due-date.  If this already
> works, then I'd argue that this bug should be closed.  If it does not, please
> attach a testcase ics file that contains such a todo, so that the developers
> can work on addressing this issue.

Thanks for your answer!

I tried importing a calendar with a task containing duration, but as far as I can see, this property is ignored. The due date is empty after importing the task. (I created this task in Sunbird, then exported the calendar, then edited to add a duration property and finally imported it in Sunbird (after deleting the original task. The resulting task is the same as the original).

Anyway it is not very clear to me how exactly the due date should be calculated based on duration. Should the duration be simply added to the start date? (obviously if the start date is present) What about working hours, weekends, etc.?

Thanks..

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Joey, it seems to me that a pretty compelling argument can be made for knowing how long a task might take before you've actually scheduled when you want to do it.  Do you disagree? 

Comment 4

[Joey Minta]

(In reply to comment #3)
> Joey, it seems to me that a pretty compelling argument can be made for knowing
> how long a task might take before you've actually scheduled when you want to do
> it.  Do you disagree? 
> 
I think it's important to note that, as gekacheka pointed out once (I think in one of the dialog-rewrite bugs), there are actually two implicit durations associated with any task.  (1) The amount of time between when the task *can* be started and when it *must* be finished.  (2) The amount of time the task will actually take to complete.  Therefore, I'm not convinced that simply tacking on a duration field will help the situation in a positive way.

On the other hand, what I could easily be persuaded of is the value of something like what Outlook does (and is mentioned in bug 274095), where the endtime picker actually displays the duration in parenthesis, something like:

[8:00pm (1.5 hours) v]
|8:15pm (1.75hours) |
|8:30pm (2 hours)   |
etc...

This conflicts sharply with our current timepicker widgets, but would, imo, much more clearly distinguish the type of duration information we are (and are not) conveying.

Comment 5

[Joey Minta]

I have a patch for this that should at least prevent the more severe bits of dataloss.  Can someone attach an ics testcase of a todo with a duration property to that I can confirm?

Comment 6

[Flavia]

Attachment: ics with a vtodo containing duration property

Comment 7

[Joey Minta]

Comment on attachment 221593 [details]
ics with a vtodo containing duration property

CREATED:20051220T150203Z
LAST-MODIFIED:20060207T123429Z
DTSTAMP:20051220T150203Z
UID:uuid1135090927562
DURATION:PT15M

What does it mean to have a duration without a DTSTART?  My patch assumed that a duration was just a shortcut of the due-date.

Comment 8

[Flavia]

(In reply to comment #7)
> (From update of attachment 221593 [details] [edit])
> CREATED:20051220T150203Z
> LAST-MODIFIED:20060207T123429Z
> DTSTAMP:20051220T150203Z
> UID:uuid1135090927562
> DURATION:PT15M
> 
> What does it mean to have a duration without a DTSTART?  My patch assumed that
> a duration was just a shortcut of the due-date.
> 

You may have tasks with an estimated duration time but not a fixed starting date. E.g. "write a letter to my grandma", you don't have an appointment for that, you just have it as a pending task, but you probably know it's going to take you 1 hour (or whatever).
Does it make it clearer?

Comment 9

[gekacheka]

With a couple extensions you can try setting duration of todos and events instead of end time.  

Calendar Item Dialog extension, extended with Duration Replacing End extension
http://www.geocities.com/gekacheka/moz/cal/ItemDialog/index.html
http://www.geocities.com/gekacheka/moz/cal/ItemDialog/extensions/durationReplacingEnd/index.html
It will be stored as todo duration in ics if there is no start, else as end (end is needed for views to display event interval). For todos, end is stored as an x-dtend property in ics.

The duration is not yet displayed in any of the views (list or mouseover), so you'll have to open the dialog again to see it in sunbird/lightning.
(For grid views, Bug 274362 blocks bug 157274.)


(The duration/due-date exclusion looks like a bug in rfc2445 4.6.2.  Instead, VTODOs should be allowed to have an end-date/duration in addition to a due date. I don't think most people think of the time remaining until a task is due as a "duration" of the task.  If someone must perform 1hr task by 9am and schedules it for 4pm the previous day, that doesn't mean it has 17hr duration, and it shouldn't block the rest of the schedule.  It also doesn't mean that it is due at 5pm, so it's ok for the schedule to slip.  So start+duration is not due date.)

Comment 10

[Joey Minta]

Not dataloss, since the DURATION is at least round-tripped.  We should still try and sort out use-cases and semantics here though.

Comment 11

[Reed Loden [:reed]]

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!

Comment 12

[Fred Jendrzejewski]

Attachment: You can see the time left until the duedate

I think that this is a nice option and if the user doesn't like it don't has to activate the column.

Comment 13

[Stefan Sitter [:ssitter]]

Comment on attachment 328570 [details]
You can see the time left until the duedate

Seems you got the wrong bug. Based on your screenshot you probably wanted to look at bug 375631 instead.

Comment 14

[Christian Jansen]

Comment on attachment 328570 [details]
You can see the time left until the duedate

Looks good to me please make sure that the column is switched off by default.

Maybe it makes sense not to shorten hours, days, etc.

ui=christian

Comment 15

[Fred Jendrzejewski]

Attachment: Duration shown

The duration is shown, the column isn't actived by default and the words are all localizable.

Comment 16

[Fred Jendrzejewski]

Attachment: A snapshot with full days hours etc.

Comment 17

[Stefan Sitter [:ssitter]]

Please note that this bug is _NOT_ about showing the duration until due date in the task list. This bug is about selecting start time + duration instead of start time + end time when creating a task. I'd prefer if you would attach your patches to the correct bug instead of hijacking this one.

Comment 18

[Fred Jendrzejewski]

I opened a bugreport under bug 444349

Comment 19

[Tom196]

Attachment: implements getter and setter for duration attribute of a task

Hi everyone,

I believe, it would make very much sense to have a duration field for tasks as you may know how long a task will take you, but you may not know yet when you'll have the time to complete it. So in order to be able to set the duration independently from a start/due date, I provided a patch which removes the readonly-constraint of this field, adds a setter and actually implements a getter. The getter for now only calculates the difference between due and start date, but totally ignores any duration-attribute. RFC2445 states that either a due date or a duration can be set. So in case, there is no duration set, the getter will still retrieve the difference between due and start.

I also implemented a UI-Part which is not quite complete yet. It'll allow to set a duration without a having a start date. The input field can also be used to specifiy a duration from a start date which will translate into a due date. Setting a due date disables the duration field. What do you think?

Comment 20

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Comment on attachment 384883 [details] [diff] [review]
implements getter and setter for duration attribute of a task

I'll take a look at this as soon as I have time.

Comment 21

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Comment on attachment 384883 [details] [diff] [review]
implements getter and setter for duration attribute of a task

Most comments are merely style nits, see https://wiki.mozilla.org/Calendar:Style_Guide


>+   * The duration of the todo, which is either set or defined as dueDate - entryDate.
>+   * Please note that null is returned if there is no duration set and entryDate or
Please wrap all changed lines at 80 characters in your patch as far as possible.

>     get duration() {
>+	var dur = this.getProperty("DURATION");
Although the file contains others, we are transitioning from var to let. Please use

let dur = this.getProperty("DURATION");

instead.


>+	  var icalDur = Components.classes["@mozilla.org/calendar/duration;1"].createInstance(Components.interfaces.calIDuration);
>+	  icalDur.icalString = dur;

We have a helper for this in calUtils. you can instead use:

let icalDur = cal.createDuration(dur);
 

>+	}
>+	else {
} else {

>+	  if (!this.entryDate)
>+	      return null;
>+	  if (!this.dueDate)
>+	      return null;
While you are changing things here, please switch to brackets even for one line if()s.

>+    set duration(value) {
>+	this.setProperty("DURATION",value);
>     },
Space after commas


r- for now, but just to get a new patch with fixed style, r+ will be faster next time (Sorry!)

Comment 22

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Another thing you should make sure is that this patch doesn't break anything that might rely on the duration being set only in certain cases (i.e start/end date is specified). Since our UI doesn't allow setting durations yet, I'm curious how a task with a DURATION set reacts in our UI.

Comment 23

[Tom196]

Hi,
thanks for your review.
I fixed those formatting errors as you said.

Concerning the UI behavior in case of a duration set: There is currently not much to worry about. The item.duration field is never read by the UI and the further used variable GDuration will only be assigned a value, if start and end date have been set. 
A Duration property in the ICS file will be converted to a due date, in case a start date has been defined. This is also my anticipated UI behavior. 
I will post a proposal for the UI part soon.

Comment 24

[Tom196]

Attachment: getter and setter for duration attribute

Comment 25

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Comment on attachment 392502 [details] [diff] [review]
getter and setter for duration attribute


>+	if (dur) {
>+		let icalDur = cal.createDuration(dur);
>+		icalDur.icalString = dur;
>+		return icalDur;
>+	} else {
>+		if (!this.entryDate) {
>+			return null;
>+		}
>+		if (!this.dueDate) {
>+			return null;
>+		}
Just a few issues now. The indentation is strange here, tabs should generally be expanded to (4) spaces. Also, calling createDuration() with an argument automatically sets the icalString, so we can even do return cal.createDuration(dur);.

I'll fix these issues myself before checkin.

r=philipp

Comment 26

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Go ahead and file a new bug for the UI part, this way we can keep things apart better in case there are regressions. 

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/2e723f74492d>
(and changeset f7e4d18acf52)

-> FIXED

Comment 27

[Stefan Sitter [:ssitter]]

You changed the calITodo interface. Doesn't this require an update of the UUID?

Comment 28

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Interface uuid changed in changeset 2ea9a2b28886

Comment 29

[Peter Lairo]

(In reply to comment #26)
> Go ahead and file a new bug for the UI part

Could someone please post the bug number here?

Comment 30

[Martin Schröder [:mschroeder]]

(In reply to comment #29)
> (In reply to comment #26)
> > Go ahead and file a new bug for the UI part
> 
> Could someone please post the bug number here?

The follow-up bug was not filed yet. Please, have a look at bug 512426 now. :)

Comment 31

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".