support for recurring tasks

I think this is a neat feature. I've started the work on this, by seperating out
the repeating event XUL stuff to a seperate overlay.
The overlay is being included, but the JS is not yet ready. There are lots of
things to think about in terms of dates that I don't want to get into, so I'm
moving this off to a future release, and sending it to <email address hidden> in
case someone else wants to take it on.

With this checkin:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcalendar&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=08%2F15%2F2003&maxdate=08%2F16%2F2003+23%3A59&cvsroot=%2Fcvsroot

tasks can now have most fields that events have including recurrence.
Since at the moment tasks are just being shown in the left side bar, there is no
neat way of showing the recurrence property.

Peter, can you provide us some insight on how you would like the repeating tasks
to show up or how Lotus Organizer does this.

Created an attachment (id=132397)
Screenshot of Organizer's Screen for Edit/Delete Repeating Task

- Repeating tasks show up on every date on each instance of the task's "Start
Date".
- The task changes color based on the "Due Date", just like any other Task.
- If a (repeating) Task's Start" or "Due" Date has passed, that task shows up
in the "Tasks" list of the current day.
- If the Task's start date is in the future, the Task doesn't show up in the
tasks list (yet).
- Optionally, if the user selects a future date as the selected date in the
calendar, any tasks that have a start date *before* that *selected date* would
appear in the Tasks List.

Theoretically, if a repeating Task is not marked "Completed" before the next
instance of that repeating task "starts", then the user would see both copies
of that repeating task.

Bssically, repeating tasks look and act just like regular tasks, except that
they are "linked" to other (identical) tasks for editing/deleting purposes.

Created an attachment (id=132398)
Screenshot of Organizer's Create Repeating Task

Organizer: "best calendar in the universe" ... I like that! :-D

RFC2445 allows for repeating tasks.

However, it does not explain how completion information might be kept separately
for different instances. (There at most one set of completion properties per
VTODO, so it appears to me that a single VTODO cannot represent multiple
instances in different states of completion.)

One partial workaround is to disable completion fields on a repeating task.
This is ok for users who just want a reminder in their calendar, but not for
users who want to be able to check the task off each time it comes up.

Are there examples of calendars which support repeating tasks that save/export
to iCal (RFC2445) format? How do they store a repeating VTODO where different
instances are in different states of completion?

*** Bug 240674 has been marked as a duplicate of this bug. ***

Peter, if Organizer exports to ICS can you paste a copy (attach) of its ICS file
with (a) repeating tasks in various stages, and (b) with at least one
non-repeating task in a stage...

I also suggest morphing this into a meta bug for repeating task issues, since
technically tasks "can" repeat in current builds. (or RESO/FIX this and making a
meta bug for that seperately)

Please don't morph bugs. I guess this bug is fixed now, and bugs for other
issues should be opened

Created an attachment (id=162450)
Repeating Event exported from Organizer as ICS file

I'm not sure this file will be a good indication of how (awesomely) Lotus
Organizer handles repeating events, since the exported ICS file could have a
syntax that is vastly different (inferior) to how Organizer tracks them with
its native format.

Created an attachment (id=162451)
Repeating Task exported from Organizer as ICS file

I'm not sure this file will be a good indication of how (awesomely) Lotus
Organizer handles repeating events, since the exported ICS file could have a
syntax that is vastly different (inferior) to how Organizer tracks them with
its native format.

The repeated task file is kind of empty. Did something go wrong, or can't you
export repeated tasks?
Also, the repeated evetns are just a bunch of events, instead of one with a
recurrance rule. Not really suited for storage.

Created an attachment (id=162455)
Repeating Task exported from Organizer as ICS file

Oops, the previous example of repeating tasks was exported incorrectly. Sorry.

I'm not sure this file will be a good indication of how (awesomely) Lotus
Organizer handles repeating tasks ("ToDo"), since the exported ICS file could
have a syntax that is vastly different (inferior) to how Organizer tracks them
with its native format.

Strangely, the repeating task only appears *once* in Lotus Organizer and in the
exported ICS file. But when I try to delete it, Organizer brings up the
"repeating-task" dialog in attachment:
https://bugzilla.mozilla.org/attachment.cgi?id=132397&action=view :-\

(In reply to comment #12)
> The repeated task file is kind of empty. Did something go wrong, or can't you
> export repeated tasks?

My bad. I exported incorrectly.

> Also, the repeated evetns are just a bunch of events, instead of one with a
> recurrance rule. Not really suited for storage.

Like I said, Lotus Organizer may be tracking repeating events/tasks
*differently* within its native format. Otherwise, it couldn't recognize such a
repeating event/task and offer the dialog in screenshot-attachment:
https://bugzilla.mozilla.org/attachment.cgi?id=132397&action=view

(In reply to comment #14)
> Like I said, Lotus Organizer may be tracking repeating events/tasks
> *differently* within its native format.

If you export a repeated task to .ics, and then try to import it, does it still
recognize it as a repeated task?
Because this is what mozcal wants. Store the .ics file on a server, and read it
from another computer. So all data must be in the ics. Stop working like this
and switching to some other fileformat would be a big switch, and not something
for this bug.

OK, I just ried re-importing the exported ICS file back into Organizer.
Unfortunately, Organizer no longer recognizes the events as "repeating"
(deleting one does not bring up the "delete repeating task" dialog). This
indicates that ICS (at least the Organizer exported version of it) does not
track repeating events. :-(

mostafah/mvl:
Can this bug be closed?

Not really. It is still not possible to complete one instance of a recurring
task while leaving the others open. We need to figure out some way to store that
data, maybe using x-properties.

Ok. So we need to figure out a way to work around a hole in 2445 :)

I propose the following workaround. A recurring task should be treated as a
standard one except that when it is completed, its recurrency is examinated: if
more instances have to take place, a new (recurring) task is automatically
created. This means, more or less, that a recurring task will have a "clone" for
each recurrence.

Do you think it could be a solution?

(In reply to comment #20)
> Do you think it could be a solution?

As a stupid user, without any knowledge of the programming involved, it seems
like this is the best solution. As a user, this is the behavior I expect. I'd
like to be able to go back to finished tasks and put in notes and not have them
show up in future instances of the task.

Please also allow repeating tasks X (days/weeks/months/etc) after completion.

*** Bug 263665 has been marked as a duplicate of this bug. ***

Change to "Base" component?

Yeah, this is definitely a "Base" issue. We should work with the CALSIFY folks
to try and get RFC 2445 clarified on this issue rather than trying to invent our
own extensions.

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

(In reply to comment #21)
> (In reply to comment #20)
> > Do you think it could be a solution?
>
> As a stupid user, without any knowledge of the programming involved, it seems
> like this is the best solution. As a user, this is the behavior I expect. I'd
> like to be able to go back to finished tasks and put in notes and not have them
> show up in future instances of the task.

It shouldn't be necessary to make multiple tasks out of a single repeating task, each task just needs the ability to:
* store its repeating interval.
* have its interval editable and store the date+time it was edited so that retrospective views of the calendar don't show the task incorrectly occurring at the latest interval. it should allow for multiple edits and the ability to discard invidual or all previous interval settings if the user doesn't care for them.
* have one section of data about the repeated task that is always visible, and again the date+time this data was edited for correct retrospective views
* have date-specific sections of data that are only visible in the calendar on individual dates. this would also mean if the interval was changed, and the old one wasn't kept for retrospective views, then the past information would still be readable in a task history dialogue box and/or by allowing the data to be read in it's nearest past-projected markers in the calendar view (with the actual date preceding the data if different form its past projected date from the new interval)

that probably doesn't read so good but i hope you get my drift.

(In reply to comment #27)

> that probably doesn't read so good but i hope you get my drift.

But can that be represented in ICS? (I ask because I don't know.)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060824 BonEcho/2.0b2
Build Identifier: 20060824

task list is not updated after editing recurrent task

Reproducible: Always

Steps to Reproduce:
1.Make sure task list and task in view are set on. In task list you can see title and due date
2.Create a task that repeats every week (set date and due date)
3.Select the task on calendar view and click 'edit selected event' (btw it should be 'edit selected task')
4.Select 'this occurrence only'
5.Change date and due date
6.click ok

Actual Results:
Task is updated in calendar view but NOT in task list. You can see old due date

Expected Results:
Task is updated in task list and calendar view

No error in console

Sorry-> I can see an error:
Error: window.startDate has no properties
Source File: chrome://calendar/content/calendar-recurrence-dialog.js
Line: 86

Note that the task list doesn't yet display anything related to occurrences.

*** Bug 360356 has been marked as a duplicate of this bug. ***

what more in multiweek view edited task just disappeard, problem with refreshing (I think this has been reported somehow) but the main problem that task panel is not updated is still valid

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Thunderbird version 1.5.0.10 (20070221) with Lightning

I created a task that repeats every Monday at 8:00. This seems to work properly, however, when I mark one instance of the task as "completed" ALL instances show the task as completed.

Reproducible: Always

Steps to Reproduce:
1.Create task to repeat every week
2.Mark first instance as complete
3.Check second and subsequent instances.
Actual Results:
The second and subsequent tasks were marked complete

Expected Results:
I expected only the first instance to be marked complete.

Jim, please describe where you create, mark and edit the task (i.e. Agenda, Todo list, Calendar view). At the moment I see only a single task in Agenda and Todo list when I create a repeating task. So I don't know where you look at your tasks.

(In reply to comment #1)
> Jim, please describe where you create, mark and edit the task (i.e. Agenda,
> Todo list, Calendar view). At the moment I see only a single task in Agenda and
> Todo list when I create a repeating task. So I don't know where you look at
> your tasks.
>
I look in the calendar Month view, which shows several of the tasks. Selecting one of the future tasks shows that it is marked completed.

*** Bug 376657 has been marked as a duplicate of this bug. ***

Duplicate of Bug 360356?

(In reply to comment #20)
> I propose the following workaround. A recurring task should be treated as a
> standard one except that when it is completed, its recurrency is examinated: if
> more instances have to take place, a new (recurring) task is automatically
> created. This means, more or less, that a recurring task will have a "clone" for
> each recurrence.

This is basically the way that Outlook behaves. When you create a repeating task only one task is created. You can choose to repeat in the normal manner (pay rent on the first of every month) or based on the time of completion (water the plants 4 days after you last watered them). In either case, when you check the box to mark the task as completed, a new task is created with the same recurrence as the original task. The recurrence is removed from the original task, and the original task remains as a standard, non-repeating, but completed task. This allows you to keep track of, for example, when you last watered the plants, or that you did indeed pay rent last month.

Although this particular interpretation may not be specified in the RFC for ICS, it seems to me like this interpretation would work with any other program that reads ICS. If you export this as an ICS file, then the completed tasks show up as separate tasks and the remaining tasks are listed as a single recurring task to be interpreted however the new program wants.

In any case, this seems (to me at least) to be an important feature lacking from Calendar. I just attempted to migrate my Outlook task list to Sunbird, and found that the majority of my tasks are repeating tasks and couldn't be properly entered into Sunbird.

This looks like duplicate (or subtask) of Bug 155889.

I believe that if there is an unbound date range offered that shows only parent items, there should also be an additional UI cue that the item is repeating, perhaps also disabling the check box to prevent the user from inadvertently marking the entire series complete as in bug 373775.

It also makes sense to me to limit the unbound date ranges offered on the task view (i.e. replacing "All" with "All current tasks" to imply a date range), while offering a separate option to show "Repeating tasks" that would show the parent items only. This would help to ensure that that the parent of a repeating item, as opposed to the next occurrences, is really what the user expects to see in the list.

Created an attachment (id=386860)
Proposed Patch for bug 350174 v1

Proposed Patch v1

1) Modifies the getItems function in calMemoryCalendar.js to allow returning of expanded occurrence sets of repeating tasks when the start date is not specified. Only the end date of a date range is necessary to determine a finite occurrence set, as the start date can be determined by the DTSTART property of the parent item.
2) Adds a new style for non-expanded parent items of repeating tasks, to distinguish between parent items and occurrences. This style will only appear in non-datebound lists. Repeating tasks are shown with blue text, as well as a "greyed out" check box to prevent inadvertantly marking the entire series as complete.
3) Disables toggling of completed status via clicking the check box for repeating parent items to resolve bug 373775.
4) Creates a new non-datebound filter option "Repeating Tasks" to show only parent items of repeating tasks .
5) Creates a new date-bound filter option "Current" to show expanded occurrences of all tasks through the selected date of the current view (the current date by default).
6) Modifies the other filter options besides "All" and "Repeating Tasks" show expanded occurrences of all tasks through the selected date of the current view.
7) Reorders the filter options to show "Current Tasks" as the default first option, as occurrences of repeating tasks are most likely what the user expects to see by default. The non-datebound "All" tasks option moved to the bottom of the list.
8) Sets the date filter of the task list in the today pane to show expanded occurrences of tasks through the current date.

Created an attachment (id=386861)
Screen Shot 1 for UI review

Created an attachment (id=386862)
Screen Shot 1 for UI review

Created an attachment (id=386863)
Screen Shot 3 for UI review

Created an attachment (id=386864)
Screen Shot 4 for UI review

Cool!!

(From update of attachment 386860)
First of all, thanks for the patch! Recurring tasks is an area we definitely need to improve.

I'll need some time to look into this, but I've noticed there are some hardcoded strings. These need to be converted to locale strings in property or dtd files. Since we are in string freeze for the beta, I'll review this after the beta.

*** Bug 509181 has been marked as a duplicate of this bug. ***

Created an attachment (id=394665)
[after beta] Proposed Patch v2

1) Fixes l10n strings
2) Updates the date filters for the corresponding task list controls when a new date is selected (ie. selecting a date in the future will show expanded occurrences of tasks starting on or before that date). In the Task View the date range is updated from the minimonth (only if _not_ defined explicitly in the selected filter, as in "All", "Today", "Next Seven Days"). In the Today Pane the getInitialDate extended binding is used to update the date range to the currently selected date in the today pane. In Sunbird the date range is determined by the date selected in the current view.

Nice one!
How do I apply this patch?

*** Bug 514587 has been marked as a duplicate of this bug. ***

Would someone please be able to help me apply this patch? I've looked around the net for how to apply patches but I still can't figure out what to do. What p level do I use? Where do I apply this patch?
This fix would be the one thing that will get me using the task list in thunderbird, which is otherwise awesome for organising things.

This shall be marked as higher priority then normal.

Created an attachment (id=404433)
[after beta] Proposed Patch v3

Fixes issue with currently started tasks not appearing in the task view if a previous date was selected. Sets the end date for the current filters to the later of the selected date in the view or the current date.

One possible behavior would be to just show the "most recent" non-completed task. Or you may have an option to display multiple non-completed recurring tasks.

One way to do this would be to spawn a new task, identical to the parent task with the exeption of the due date. The new task would be spawned when the current task is marked as complete.

So, It's 1/1/09 and I want to create a task that due due on the 15th of each month. I create a new task, set the due date to 1/15/09, the start date could be set the same as the 'initial' due date. I set the recurrence to "monthly" and set the reminder to 5 minutes, or whatever.

On 1/15/09, I am reminded to do my task. But, I'm lazy so I hit the snooze button a few times. Finally, I do my task, dismiss the reminder and mark the recurring task complete.

When I check the "complete" box, it is struck-though as completed and a "new task" is created that is identical to the task I just completed but the due date of the new task is 2/15/09, also with a reminder.

I think this behavior ideal since althoug seeing multiple incomplete tasks may be a bonus in some cases.

Any idea when the new functionality will be available or if it is avaialable, how do I install it? I'm moving over from outlook and not having working recurring tasks is a deal breaker for me. I hate to say that since I love all the other features.

As others have said: the ineffectiveness of repeating tasks is a major gamebreaker in the functionality of Sunbird or Lightning as compared to Outlook.

As far as I can tell, this bug and those it "blocks" bug 373775 , bug 438310 , and bug 500114 , have not been worked on in several months. I do not know what the proposed patch about does, but if it helps make repeating tasks more functional, what is delaying it's integration into a Thunderbird build? And if it will not be, is there a standalone patch or addon that helps the functionality of tasks in Thunderbird?

(From update of attachment 404433)
> function minimonthPick(aNewDate) {
>- if (isSunbird() || gCurrentMode == "calendar") {
>+ if (isSunbird() || gCurrentMode == "calendar" || gCurrentMode == "task") {
Go ahead and use cal.isSunbird() instead, here and elsewhere.

>+ // prevent toggling completed status for parent items of repeating tasks
>+ if (!task || task.recurrenceInfo)
> return;
While you're here, please add {}, even for one-line if's

> onAddItem: function tTO_onAddItem(aItem) {
...
>+ let occs;
>+ if (this.binding.mFilter.endDate) {
>+ occs = aItem.getOccurrencesBetween(this.binding.mFilter.startDate,
>+ this.binding.mFilter.endDate,
>+ {});
Lets be more robust here and also check if the start date isn't null.

>+ }
>+ for each (let occ in occs) {
>+ this.binding.mTreeView.removeItem(occ);
>+ }
If you like:
  occs.forEach(this.binding.mTreeView.removeItem, this.binding.mTreeView);

>
>- if (savedThis.mFilter.startDate && savedThis.mFilter.endDate) {
>+ if (savedThis.mFilter.endDate) {
> filter |= aCalendar.ITEM_FILTER_CLASS_OCCURRENCES;
> }
Same comment as before, this time I have the feeling you did it for a reason :-) Why only check for end date here? Can't we be more robust and also check for the start date?

>+ let oneDay = createDuration();
Please prefix everything you use from calUtils.js with "cal.", we are transitioning to the use of the calUtils.jsm module. If you get an error that it is not defined, add

Components.utils.import("resource://calendar/modules/calUtils.jsm");

in the constructor.

>+ // add listener to update the date filters
>+ getViewDeck().addEventListener("dayselect", updateCalendarToDoUnifinder, false);
>+
> function getDatesForFilter(aFilter) {
>- var EndDate = createDateTime();
>- var StartDate = createDateTime();
>- var Duration = createDuration();
>+ var endDate = createDateTime();
>+ var startDate = createDateTime();
>+ var duration = createDuration();
> var oneDay = createDuration();
Go ahead and change all var's to let's in this function.

>+.calendar-task-tree > treechildren::-moz-tree-cell-text(repeating) {
>+ color: blue;
>+}
The css style rules seem the same between windows and mac. Please put the rules in the respective files in base/themes/common. If there is no file for the task tree, then go ahead and create one, including it via @import (similar to how the other common files are included)

> if (itemReturnOccurrences && item.recurrenceInfo) {
>+ let startDate = aRangeStart;
>+ if (!aRangeStart && isToDo(item))
>+ startDate = item.entryDate;
Please use {} for this if statement. If you like, please also change var to let.

The code looks fine, r- just to get a new patch with nits fixed. Waiting for ui-review now, ...

Created an attachment (id=429730)
Proposed Patch v3 - debitrottee

For testing I needed to make the patch apply, so here is the debitrotted patch. I did notice some issues with the patch though. For me, changing the task filter doesn't change the displayed tasks at all. STR:

* Apply patch, start Lightning, go to task view
* Create a few tasks with the quick add feature
* Switch through the filters

Result:

* All tasks are shown, regardless of what filter is chosen.

>+ // add listener to update the date filters
>+ getViewDeck().addEventListener("dayselect", updateCalendarToDoUnifinder, false);

If you add the listener here, you need to remove it somewhere too. I believe we have a finish function for the unifinder too.

> I did notice some issues with the patch though. For me, changing the task
> filter doesn't change the displayed tasks at all. STR:
>
>
> * Apply patch, start Lightning, go to task view
> * Create a few tasks with the quick add feature
> * Switch through the filters
>
> Result:
>
> * All tasks are shown, regardless of what filter is chosen.

I'm not able to reproduce this - for me the old filters work the same way as without the patch applied until some tasks are set as repeating (which is how its supposed to work). Can you provide more details of which filter is selected and which tasks are still showing when they shouldn't? Do you show any errors?

> > onAddItem: function tTO_onAddItem(aItem) {
> ...
> >+ let occs;
> >+ if (this.binding.mFilter.endDate) {
> >+ occs = aItem.getOccurrencesBetween(this.binding.mFilter.startDate,
> >+ this.binding.mFilter.endDate,
> >+ {});
> Lets be more robust here and also check if the start date isn't null.

> >- if (savedThis.mFilter.startDate && savedThis.mFilter.endDate) {
> >+ if (savedThis.mFilter.endDate) {
> > filter |= aCalendar.ITEM_FILTER_CLASS_OCCURRENCES;
> > }
> Same comment as before, this time I have the feeling you did it for a reason
> :-) Why only check for end date here? Can't we be more robust and also check
> for the start date?

In both cases the startDate is now made optional for expanding occurrences by this:

> > if (itemReturnOccurrences && item.recurrenceInfo) {
> >+ let startDate = aRangeStart;
> >+ if (!aRangeStart && isToDo(item))
> >+ startDate = item.entryDate;

If the startDate is set it is used, and if it isn't the start date of the each parent task is used. The check remains for the endDate, if it is not provided then occurrences are not expanded. This allows for for filters like "show occurrences for all repeating tasks through 3/2/2010", and is the basis for allowing expansion of a finite occurrence set based on the date selected in the view or today pane. I added the isToDo() check to avoid inadvertently breaking any other code that relies on the old expansion requirements.

Created an attachment (id=429933)
Proposed Patch v4

Patch with requested fixes

*** Bug 536933 has been marked as a duplicate of this bug. ***

*** Bug 552261 has been marked as a duplicate of this bug. ***

Now that bug 350174 has been fixed, could someone create an ics in outlook where a recurring task with alarms has several instances completed and one instance with a snoozed alarm? I think we could choose to follow the way outlook does this (unless it's really ugly).

(In reply to comment #42)
> Now that bug 350174 has been fixed, could someone create an ics in outlook
> where a recurring task with alarms has several instances completed and one
> instance with a snoozed alarm? I think we could choose to follow the way
> outlook does this (unless it's really ugly).

Outlook 2007 does not have a native ICS export for tasks. I tried exporting as a CSV/tab-delimited text file, but all that did was create a unique record for every occurrence within a date range I specified during the export wizard.

Hey, on Sunday this bug will be four years old. What's appropriate? cake? candles? Should we bring gifts?

The cake is a lie.

Great comment, made my day. Very funny.

Others in this thread have compared behavior on this bug to Outlock, but I'll be cold and dead before I willingly use that. For those who are still waiting for resolution on this, check out www.rememberthemilk.com. They have a free version, and it works more or less how I was wanting lightning/thunderbird to work. I don't work for 'em or anything, so hopefully I won't get in trouble with this comment. :)

Bug 350174 has been fixed already. I suggest that you retest using a current Lightning nightly build.

Ok, back to serious now. I want this bug fixed as much as you do, but the aforementioned calendar-standards problem is really the showstopper here. I have recurring tasks to, and some tasks I have not entered in my calendar because I know we don't handle them in a good way for the user.

Given we come to a consensus on a good concept, both in backend and frontend and then find someone with time and ambitions to fix this bug, this bug will progress.

Is there still an outstanding issue here that wasn't fixed by bug 350174?

Great to hear it's in the nightly! A quick check indicates it, indeed, works.

Thanks very much!

Lance

Hmm does that mean we can close this bug? For that to happen, all places where tasks can be modified it should not be ambiguous if the master event or an occurrence is being modified.

I would call this FIXED, unless there are any other issues I'm not aware of.

Additional to Comment 51, it should not be easy to modify a master event in error, must be user-friendly for unsophisticated users.

I did notice something kind of weird: If you go to a future date, all your repeating tasks stack-up in the tasks area. It seems to not be aware that you're looking into the future, it just assumes you're that far behind in completing all those repeating tasks.

Note: I'm not saying this is a real problem (at least for me), it just seems rather odd.

Does anyone have real issues with this behaviour?

Ok, given the amount of comments here I think it will be easier if we file a new bug to fix the tasks piling up issue. I'd appreciate if someone could do that, feel free to mark it as NEW if you can.

Marking FIXED by bug 350174.

*** Bug 646951 has been marked as a duplicate of this bug. ***