The default bug view has changed. See this FAQ.

Support optional default Start and Due dates for Tasks

RESOLVED FIXED in 3.3

Status

Calendar
Tasks
--
enhancement
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: Adam Katz, Assigned: mmecca)

Tracking

unspecified

Details

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

8 years ago
Most of the tasks I create use the "Today Pane" in Thunderbird's email view.  I click the bottom area to create a new task and enter something in.  It comes with no information at all, specifically regarding dates.  This is a problem for me.

I would like the creation time noted by default.

I would like to be able to set a default due date along the lines of "5pm tomorrow" or "5pm this Friday" (or if we want to be clever, that latter one should be "5pm on the Friday following tomorrow at 5:01pm" so it doesn't create <25h deadlines).

This means that with a default due date of "5pm tomorrow", when I create a task by entering something in Today Pane's "Click Here to Add a New Task," it automatically creates the task with a due date of 5pm the next day.  If I were using the "New Task" dialog, a Due Date of the following day at 5:00pm would be entered and checked automatically.

Ditto for start date.  I'd like to be able to configure the system to default to a start date like "right now" or "9am tomorrow" or "9am Monday."

As it currently stands, sorting tasks by date is completely messed up since un-dated items are regarded as ~1969 rather than ~2071.  Even if we add an option for default due dates, this will be an issue for people who don't activate them.
This feature needs some UI that doesn't overload the prefs pane. I don't think the core code should be too complex on this, but some defaults for due and start dates (i.e task templates) could work out.

Please search/file a separate bug for the sorting issue.
Keywords: uiwanted
OS: Linux → All
Hardware: x86 → All
Version: Lightning 0.9 → unspecified
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 361213
Keywords: uiwanted
(Assignee)

Comment 3

3 years ago
If it's OK with you Philipp I'd like to reconsider this as a regular pref, I think it complements the default event length preference, and would be really useful with the quick add feature of the task lists, independent of the event dialog and template UI discussed in Bug 361213.
Assignee: nobody → matthew.mecca
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: [RFE] Default times for tasks: creation time, options for default start and due dates → Support optional default Start and Due dates for Tasks
(Assignee)

Comment 4

3 years ago
Created attachment 8333537 [details] [diff] [review]
Fix v1

Adds general prefs for default start and due dates. Options include: start/end of current day, next day, or next week as defined by the view settings; a fixed offset in minutes from the current time / start date; and a fixed offset in minutes from the start of the next hour.
Attachment #8333537 - Flags: ui-review?(richard.marti)
Attachment #8333537 - Flags: review?(philipp)
(Assignee)

Updated

3 years ago
Status: REOPENED → ASSIGNED
Comment on attachment 8333537 [details] [diff] [review]
Fix v1

Review of attachment 8333537 [details] [diff] [review]:
-----------------------------------------------------------------

For me this looks good. Only one thing, you are using in offsets minutes up to 999 (a little bit more than 16 hours). Should this work in such fine granularity for tasks? Wouldn't it be better to use hours instead. I'm not using Tasks but i think tasks are for longer periods and a shortest period of 1 hour should be enough.

Again, I'm not using tasks and this is only to think about it.
Attachment #8333537 - Flags: ui-review?(richard.marti) → ui-review+
Comment on attachment 8333537 [details] [diff] [review]
Fix v1

Review of attachment 8333537 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me, r=philipp

::: calendar/base/content/calendar-item-editing.js
@@ +20,5 @@
>  
> +function setDefaultItemValues(aItem, aCalendar, aStartDate, aEndDate, aInitialDate, aForceAllday) {
> +    function endOfDay(aDate) {
> +        let eod = aDate ? aDate.clone() : cal.now();
> +        eod.hour = getPrefSafe("calendar.view.dayendhour", 19);

cal.getPrefSafe

@@ +27,5 @@
> +        return eod;
> +    }
> +    function startOfDay(aDate) {
> +        let sod = aDate ? aDate.clone() : cal.now();
> +        sod.hour = getPrefSafe("calendar.view.daystarthour", 8);

cal.getPrefSafe

@@ +43,5 @@
> +            if (aStartDate.isDate && !aForceAllday) {
> +                // This is a special case where the date is specified, but the
> +                // time is not. To take care, we setup up the time to our
> +                // default event start time.
> +                aItem.startDate = getDefaultStartDate(aItem.startDate);

cal.getDefaultStartDate

@@ +53,5 @@
> +            }
> +        } else {
> +            // If no start date was passed, then default to the next full hour
> +            // of today, but with the date of the selected day
> +            aItem.startDate = getDefaultStartDate(initialDate);

cal.getDefaultStartDate

::: calendar/base/content/calendar-task-editing.js
@@ +129,2 @@
>              if (edit.value && edit.value.length > 0) {
> +                let item = createTodo();

cal.createTodo while you are here.

::: calendar/locales/en-US/chrome/calendar/preferences/general.dtd
@@ +24,5 @@
> +<!ENTITY pref.default_todo_tomorrow.label "Tomorrow">
> +<!ENTITY pref.default_todo_next_week.label "Next Week">
> +<!ENTITY pref.default_todo_offset_current.label "Offset From Current">
> +<!ENTITY pref.default_todo_offset_start.label "Offset From Start">
> +<!ENTITY pref.default_todo_offset_next_hour.label "Offset From Next Hour">

Would everyone understand what "Offset From Current" means? Maybe something like "Relative to Start", "Relative to Next Hour" for the lower two, I'm not quite sure what "current" is? The current time? In that case "Relative to current time".

Alternatively, if things are getting too long, maybe its possible to add a tooltip? Although I think a tooltip on a menuitem won't work.
Attachment #8333537 - Flags: review?(philipp) → review+
Created attachment 8393267 [details] [diff] [review]
Fix - v2

Hi Matt, I've picked this one up again while trying to clear bug 731723 from my review queue. Here is a debitrotted patch with review comments applied. The only thing I haven't done is the strings, waiting for your feedback there. A few further comments:

* "Offset from Current" and "Offset from next hour" are very close to each other. Do we really need both options? If I had to pick, I'd stick with only "offset from current".

* Possibly the strings in the tasks dropdown should be put in a more general location. I could imagine a new feature (for a followup bug) that gives any "new task" button a dropdown where you can select when the task being created is due (End of Day, Tomorrow, ...)

* I sometimes with JS had python-style arguments. The argument list for setDefaultItemValues could potentially get very long. Maybe it would be better to have a parameter "args" which is an object and contains all the optional properties?

These are rather FYI:

* The defaults section looks a little unordered to me. As time permits I will solve this in another bug by moving the snooze prop to the alarms pane, putting the defaults into its own groupbox and creating a dropdown connected to a deck so that events/tasks defaults can be set separately.

* Arranging these controls would probably look better in a grid. I'll take care of this in above mentioned bug.
Attachment #8333537 - Attachment is obsolete: true
Attachment #8393267 - Flags: review+
Attachment #8393267 - Flags: feedback?(matthew.mecca)
Created attachment 8393804 [details] [diff] [review]
Fix - v3

Heya. I've made a few changes to your patch to directly incorporate the deck. I'd appreciate a review on this before you push.
Attachment #8393267 - Attachment is obsolete: true
Attachment #8393267 - Flags: feedback?(matthew.mecca)
Attachment #8393804 - Flags: review?(matthew.mecca)
Oh, one thing I forgot, I think we should use "task" instead of "todo" in more places in that patch, i.e the preferences.
Comment on attachment 8393804 [details] [diff] [review]
Fix - v3

Review of attachment 8393804 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/base/content/preferences/general.xul
@@ +86,5 @@
> +            <menulist id="defaults-itemtype-menulist" oncommand="gCalendarGeneralPane.updateItemtypeDeck()">
> +                <menupopup id="defaults-itemtype-menupopup">
> +                    <menuitem id="defaults-itemtype-event"
> +                              label="&pref.events.label;"
> +                              value="default-event-grid"/>

s/default/defaults/

Sorry for all the mistakes :)
Created attachment 8394086 [details] [diff] [review]
Fix - v4

v4 addresses a few of my previous comments. I decided not to move the strings into a general location for the new tasks feature just yet. I also decided to stick with the current argument format for setItemDefaults for now.
Attachment #8393804 - Attachment is obsolete: true
Attachment #8393804 - Flags: review?(matthew.mecca)
Attachment #8394086 - Flags: review?(matthew.mecca)
(Assignee)

Comment 12

3 years ago
I think Richard makes a good point in comment #5, while I think we should keep the minute resolution as the default I think we should also offer the option to specify hours and days as a unit for the offsets, similarly to how the default reminders pref works. I have a version of the patch locally that makes those changes, I'll merge those with your changes and put up a new patch.
(Assignee)

Comment 13

3 years ago
Created attachment 8394547 [details] [diff] [review]
Fix v5

This adds a dropdown to select the unit for custom offsets. I added another column to the grid to get everything lined up correctly.
Attachment #8394086 - Attachment is obsolete: true
Attachment #8394086 - Flags: review?(matthew.mecca)
Attachment #8394547 - Flags: ui-review?(richard.marti)
Attachment #8394547 - Flags: review?(philipp)
Comment on attachment 8394547 [details] [diff] [review]
Fix v5

Review of attachment 8394547 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, one thing we should take care of:

::: calendar/base/content/calendar-ui-utils.js
@@ +437,1 @@
>      }

Shouldn't we be using PluralForm instead?
Attachment #8394547 - Flags: review?(philipp) → review+
Comment on attachment 8394547 [details] [diff] [review]
Fix v5

Review of attachment 8394547 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
Attachment #8394547 - Flags: ui-review?(richard.marti) → ui-review+
(Assignee)

Comment 16

3 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #14)
> Comment on attachment 8394547 [details] [diff] [review]
> Fix v5
> 
> Review of attachment 8394547 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good, one thing we should take care of:
> 
> ::: calendar/base/content/calendar-ui-utils.js
> @@ +437,1 @@
> >      }
> 
> Shouldn't we be using PluralForm instead?

Yes, I also noticed there is an almost identical function at [1] that can be consolidated here as well, but I think that's better done in a separate bug.

[1] http://mxr.mozilla.org/comm-central/source/calendar/base/content/preferences/alarms.js#33
(In reply to Matthew Mecca [:mmecca] from comment #16)

> Yes, I also noticed there is an almost identical function at [1] that can be
> consolidated here as well, but I think that's better done in a separate bug.

Ok, lets do that. Can you file the bug when you push?
(Assignee)

Updated

3 years ago
Blocks: 986850
(Assignee)

Comment 18

3 years ago
https://hg.mozilla.org/comm-central/rev/6ebe3fce935c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.3
You need to log in before you can comment on or make changes to this bug.