support for recurring tasks

[aleneguou]

One very useful feature would be recurring to-do list items, that repeat a set interval after the most recent completion.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: sunbird 0.8+nobinonly-0ubuntu1
ProcEnviron:
 LANGUAGE=en_US:en
 PATH: custom, no user
 LANG=en_US
 SHELL=/bin/bash
SourcePackage: lightning-sunbird
Uname: Linux 2.6.28-2-generic i686

[Mikeypotter (mikeypotter)]

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.

[Mostafah (mostafah)]

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.

[Mostafah (mostafah)]

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

[Peter-lairo (peter-lairo)]

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.

[Peter-lairo (peter-lairo)]

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

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

[Gekacheka (gekacheka)]

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?

[Mvl (mvl)]

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

[Justin Wood (Callek) (bugspam-callek)]

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)

[Mvl (mvl)]

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

[Peter-lairo (peter-lairo)]

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.

[Peter-lairo (peter-lairo)]

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.

[Mvl (mvl)]

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.

[Peter-lairo (peter-lairo)]

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 :-\

[Peter-lairo (peter-lairo)]

(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

[Mvl (mvl)]

(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.

[Peter-lairo (peter-lairo)]

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. :-(

[Lilmatt (lilmatt)]

mostafah/mvl:
Can this bug be closed?

[Mvl (mvl)]

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.

[Lilmatt (lilmatt)]

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

[Lou-latoserver (lou-latoserver)]

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?

[Realtegan (realtegan)]

(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.

[aleneguou (alexandergould)]

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

[Joey Minta (jminta)]

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

[Worcester12345 (worcester12345)]

Change to "Base" component?

[Dmose (dmose)]

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.

[Lilmatt (lilmatt)]

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

Bugspam filter: TorontoMostafaMove

[Lucas-serverart (lucas-serverart)]

(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.

[Jonblake (jonblake)]

(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.)

[Omar (omarb-public)]

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

[Omar (omarb-public)]

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

[Joey Minta (jminta)]

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

[Ssitter (ssitter)]

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

[Damian-publicemail (damian-publicemail)]

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

[Neoscona (neoscona)]

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.

[Mschroeder-mozilla (mschroeder-mozilla)]

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.

[Neoscona (neoscona)]

(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.

[Philipp-bugzilla (philipp-bugzilla)]

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

[Ssitter (ssitter)]

Duplicate of Bug 360356?

[Benjamin Kraus (ben-benkraus)]

(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.

[Benjamin Kraus (ben-benkraus)]

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

[Benjamin Kraus (ben-benkraus)]

Or it is a duplicate of Bug 155889.

[Benjamin Kraus (ben-benkraus)]

Oops, meant to say:
Or is it a duplicate of Bug 350174.

[Benjamin Kraus (ben-benkraus)]

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

[Sebo-moz (sebo-moz)]

Repeating tasks are possible by now. Nominating for WORKSFORME.

[Colby (cek1227)]

That seems to be how RTM works, too. There are two things that prevent me from using Calendar - this feature (the primary reason), and the inability to update RTM tasks (less important, if the first one gets fixed).

[Sebo-moz (sebo-moz)]

I am sorry, I didn't read through the whole bug. It looks like the remaining issue is better described by bug 373775? Are there other open issues?

[ctalbert (ctalbert)]

Marking as WFM because the basic issue here was resolved: Repeating Tasks. The "What to do when a repeating task is completed" should be its own bug, and I encourage everyone to use bug 373775 for that design and discussion.

[ctalbert (ctalbert)]

Marking as "depends on" 155889. This bug should be used to drive the discussion over the "what to do when a repeating task is completed" question. Also confirming the bug too.

[bvdbos (bvdbos)]

I don't know how other progams handle this but as in fact we're altering a specific instance of a recurrence-set I think there'should be no x-props but this should be handled like every other edit of a recurrence-item. The same holds for alarms on recurrent items BTW.

[Benjamin Kraus (ben-benkraus)]

There's some discussion in the comments to Bug 155889 about how other programs handle repeating tasks. I'll just point there (bug 155889) rather than attempting to repeat the discussion here.

[Bugzilla-babylonsounds (bugzilla-babylonsounds)]

Not going to happen for 0.8.

[Omar (omarb-public)]

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

[Ssitter (ssitter)]

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

[bvdbos (bvdbos)]

As bug 368976 was fixed with buggy cloning perhaps the same sort of logic can be used here? Marking a repeating task complete makes it an exception and modifies the specific exception?

[Ssitter (ssitter)]

Updating summary because this is a general issue, see comment #2.

[Ssitter (ssitter)]

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

[Ssitter (ssitter)]

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

[nemoinis (nemoinis)]

I aggree with comments 8 & 13. Marking a repeating task as completed should create a single non-recurring instance of that task and mark that instance only as completed; the repeating task itself should then be adjusted to the next repeat date.
This leaves a permanent trace of when each instance was completed, including any notes, etc.. pertaining to that instance.
The current behaviour of marking all instances complete is unacceptable (on a personal note, I almost missed a mortgage payment because of that).

[Dbo-moz (dbo-moz)]

I think this generally falls into "how do we want to display infinitely recurring items in unbound lists". I can imagine we could
a) Avoid/don't offer unbound lists (e.g. remove "All Events" in unifinder, "All" tasks in task mode).
b) Dynamically expand the list while scrolling the output.

[Tmatous (tmatous)]

This bug has been around for quite a while. I think the severity ought to be higher than "normal", as it leaves recurring tasks completely unusable.

Recurring tasks is the only reason I installed Sunbird, since iCal does not support recurring tasks, and Google doesn't have tasks at all. I don't want to install Office!!

Any status on this bug?

[Sshoemaker (sshoemaker)]

This leaves recurring tasks COMPLETELY UNUSABLE! I am wanting to use Thunderbird/Lightning for my organization (in a bid to finally rid us from the M$ Borg)... however recurring tasks are a MAJOR sticking point!

If they don't work, my migration plan goes up in smoke.

[admiralnemo (admiralnemo)]

I agree with Tony and Seth, recurring tasks might as well not be implemented if this is how they are treated.

I don't mean to flame, I am genuinely curious, but what is it that makes this so difficult to implement? For calendar events, it seems pretty trivial to create the orphaned instance, what is different about tasks? Is this something not easily supported by iCalendar/vCalendar?

Any developers' insight would be really appreciated. At the very least, it would shut up us annoying users :)

[Philipp-bugzilla (philipp-bugzilla)]

The problem is a bit with how to best put this into ics:

If we would be creating exceptions for each completed task, then the calendar would get quite large only due to completed tasks. Also, editing a once completed task would not modify the whole series but the exception.

If we set an X-Prop similar to alarms that all tasks after date N are completed, this wont be portable any time in the future and its not possible to have last weeks occurrence not completed but this weeks occurrence completed. Also its unclear how the completed state on the item itself should be.

I'd personally like to have working recurring tasks too, but its not easy to find a working concept here, as you see that other applications don't implement it at all :-)

[Benjamin Kraus (ben-benkraus)]

(In reply to comment #18)
> If we would be creating exceptions for each completed task, then the calendar
> would get quite large only due to completed tasks.

How much of a problem is the size of the calendar due to completed tasks? Right now, the only way to implement repeating tasks is to create a separate task for each occurrence, so fixing this bug should produce a decrease in the size of the calendar (it would only need to store past completed occurrences, not every occurrence).

(In reply to comment #18)
> Also, editing a once completed task would not modify the whole series but the
> exception.

If I want to effect the whole series, I would modify the future tasks, not the already completed tasks. When I make a change to future (or uncompleted) occurrences, I generally want that change to effect all future occurrences, but I don't want that change to effect completed tasks. In the rare case that I modify an already completed task, I don't think I would want that change to effect all future occurrences.

This is the way that Outlook behaves, once a task is completed it is completely isolated from the remainder of the occurrences. I think it is kind of intuitive.

(In reply to comment #18)
> If we set an X-Prop similar to alarms that all tasks after date N are
> completed, this wont be portable any time in the future and its not possible to
> have last weeks occurrence not completed but this weeks occurrence completed.

Perhaps an X-Prop could be created that lists which occurrences of the task have been completed?
I'm not familiar with X-Props, but if the same X-Prop can exist multiple times in a single task, maybe each completed occurrence can create a new entry that says which occurrence was completed and when it was completed?

(In reply to comment #18)
> Also its unclear how the completed state on the item itself should be.

If you go with the X-Prop approach, the completed state on the item itself would be pretty much ignored. However, I suppose it could indicate whether all occurrences of the task are completed (basically as it behaves now).

(In reply to comment #18)
> I'd personally like to have working recurring tasks too, but its not easy to
> find a working concept here, as you see that other applications don't
> implement it at all :-)

There are at least a few applications that do implement repeating tasks (RTM and Microsoft Outlook are the two that come to my mind). Are there any applications that support both ICS and have a good implementation of repeating tasks?

Also, is there a place to discuss possible implementations (a wiki page perhaps), or is this bug the place?

[Sshoemaker (sshoemaker)]

Outlook supports recurring tasks, and most people (at least those I come in contact with) do not care about tasks once marked complete -- therefore with recurring tasks, keep them for a month and then purge. With Outlook, once marked complete, next week's task shows up and you know that you have to do that task again for next week, and when one is over due, they will BOTH show up. This is great functionality.... however just the wrong software manufacturer... :)

[Philipp-bugzilla (philipp-bugzilla)]

The best place for discussion is the newsgroups (mozilla.dev.apps.calendar), but please remember that we are quite low on manpower and have a bunch of other things to fix too. Don't expect this bug to be fixed quickly just because there was a newsgroup discussion on it ;-)

If you are interested in fixing this bug yourself, I can hook you up with the right prerequisites to do so. Contact me per email in that case.

[Ssitter (ssitter)]

Please note that this is just an issue with the task list control. If you edit the tasks from within the main calendar view (after enabling the Task in View option) it should work correctly.

[Bo-darsenius (bo-darsenius)]

I must agree: Recurring tasks is a very important feature, but as it is now, it is almost unusable in Sunbird. Please set a higher priority to this "bug"!

[Tmatous (tmatous)]

(In reply to comment #22)
> Please note that this is just an issue with the task list control. If you edit
> the tasks from within the main calendar view (after enabling the Task in View
> option) it should work correctly.
>

The point of tasks is that you have a _task_ to complete. It should stay there in a list until you complete it. If your software allows that task to slip away on the calendar without being completed, your software is not helping you manage tasks.

[Stefan Sassenberg (stefan-sassenberg)]

I second the motion. Please give this bug a higher priority: recurring tasks are unusable at present.

[Ssitter (ssitter)]

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

[Ssitter (ssitter)]

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

[Tintinux (tintinux)]

This bug is now the most important thing to fix in Lightning or Sunbird, the only reason why I can't use it at Office, and have to go on with MS.

The comment #22 is a bit silly... Most people will ignore or forget it. A workaround should be advisable when the normal way do not work, not when it work silently in the wrong way.

[Benjamin Kraus (ben-benkraus)]

My response to comment #22 is that it shows how easily fixed this bug will be once the underlying bug (bug 350174) is fixed. In other words, the reason this bug exists is because the task list only shows the parent task, not individual recurrences. Once the task list is showing individual recurrences, the task list will behave just like viewing tasks from within the main calendar view, and should work properly.

[Cmichaelis (cmichaelis)]

For what it's worth, I concur with comment #20 above. This is the only problem preventing me from dropping all other software and just using Sunbird/Thunderbird+Lightning for all task tracking/calendaring.

Thanks!

[Jane-2494 (jane-2494)]

It looks like the fix would be to take the logic behind what Benjamin Kraus has said (comment #29 above as well as comment #30 at https://bugzilla.mozilla.org/show_bug.cgi?id=155889 ) and improve the user interface to reflect this logic. As pointed out by Benjamin Kraus, https://bugzilla.mozilla.org/show_bug.cgi?id=350174 might also be related to this issue.

Let's wrap all three issues into one fix by slightly altering Benjamin's words as I understand them in order to resolve these three issues.

When one creates a repeating task only one task is (and should be) created. You can choose to repeat this task in the normal manner. When you check the box to mark the task as completed, two things should happen. Firstly, the old/completed task is changed as a standard, non-repeating task and recorded in the storage.sdb database. Secondly, a NEW task is automatically (behind the scenes) created with the same recurrence as the original (now completed) task. This new task will have a start date and time of the NEXT recurrence and a due date and time (if any) of the next recurrence. That addresses the logic part of this problem.

To address the rest of this problem the user interface needs to be enhanced (I believe easily). Currently, the task list displays only one checkbox option as "Show completed tasks." Replace this checkbox with a list box (sometimes called a pulldown menu). The options displayed in the list box are very similar the the current list box already included for events, namely:
* Today's tasks
* Tasks in the next 7 Days
* Tasks in the next 14 Days
* Tasks in the next 31 Days
* Tasks in the next Calendar Month
* Currently Selected Day
* All Tasks
* Completed Tasks
* Uncompleted Tasks
I believe these options are simply filters based on properties of each task/event. For example, in the iCalendar file all options could be filtered based on just two properties: the DTSTART and X-MOZ-GENERATION (see RFC 2445).

Notes:
The list box approach would make the concerns regarding bug #350174 raised at https://bugzilla.mozilla.org/show_bug.cgi?id=350174 a non-issue.

By having the original task recorded and remain in the database as a standard, non-repeating allows us to keep track of, for example, when you last
watered the plants, or that you did indeed pay rent last month. Benjamin's comment #19 above addresses the database file size concern.

This particular logic would work with any other programs that read ICS. Specifically, 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 that new program wants.

[Jane-2494 (jane-2494)]

See https://bugzilla.mozilla.org/show_bug.cgi?id=373775#c29 for a possible resolution.

[aleneguou (alexandergould)]

One very useful feature would be recurring to-do list items, that repeat a set interval after the most recent completion.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: sunbird 0.8+nobinonly-0ubuntu1
ProcEnviron:
 LANGUAGE=en_US:en
 PATH: custom, no user
 LANG=en_US
 SHELL=/bin/bash
SourcePackage: lightning-sunbird
Uname: Linux 2.6.28-2-generic i686

[Dmose (dmose)]

Marking as tb-integration+; this feels like too confusing of a user experience to ship with. If this turns out to be a lot of work to fix, one conceivable option for keeping this bug from blocking would be to temporarily disable repeating tasks for the initial tb-integration release.

[Jane-2494 (jane-2494)]

Maybe my verbosity in explaining caused it to feel too confusing of a user experience, but it is the same thing we currently do with events. :-)

You can see this if you toggle on "Find Events." To toggle "Find Events" on using Sunbird version 0.9 you would select Edit | Find Events. There you can see what I am talking about in my verbose post. :-) Hope that helps.

[Dbo-moz (dbo-moz)]

I agree with Benjamin about the underlying "bug", i.e. how to show infinite recurring items in "unbound" views. In general the same problem is apparent in the unifinder, too, I've blogged about it some time ago [1] and I suspect the sole reason to show only parent items has been this problem.

So IMO the question here is more like: How should we show up "All Tasks" w.r.t. infinite recurring ones?

[1]
<http://weblogs.mozillazine.org/calendar/2008/08/daniels_developer_notes_how_to.html>

[John Vivirito (gnomefreak)]

seems the upstream bugs have gotten confusing and have marked as dupes and as WFM so i went with ending bug in the process.

[John Vivirito (gnomefreak)]

marking confirmed since we have upstream bug

[John Vivirito (gnomefreak)]

We dont need any more information on our end however you may need to add to upstream bug report im marking as triaged

[nemoinis (nemoinis)]

#31, there is a flaw in your logic: it assumes a recurring task is marked complete before the next recurrence occurs. This may not be the case.

For example, if I have a recurring monthly task "generate a sales tax report", and I let June, July and August pass without doing anything, I would expect 3 task instances to show up: one each for June, July, August (My tax auditor would expect it too!) And I should be able to complete August's task before I go back and complete June's, if that suits my workflow better. Comments #20 and #25 have got it right.

[Benjamin Kraus (ben-benkraus)]

You are correct that the logic in comment #31 requires you to mark a recurring task as complete before the next recurrence, but it doesn't have to stay marked complete. Perhaps this isn't the best solution, but if you find yourself in the scenario described in comment #35: When you decide to complete August's sales tax report you simply mark June as complete then mark it as incomplete again. Upon marking it as complete, it will generate a new task for July, but leave behind the task for June as an isolated task which can be modified as you please. So, the complete set of operations would be:

1) Mark June as complete then immediately mark it as incomplete.
2) Mark July as complete then immediately mark it as incomplete.
3) Mark August as complete (assuming you've finished August's report)

The result is regular (incomplete, non-recurring) tasks for June and July, a completed task for August, and a new recurring task for September. This is how I used to use Outlook before I switched to Lightning, and it worked out nicely (and having to go though those steps reminds me just how far behind I was on my recurring tasks).

- Ben

[Dave-mozilla (dave-mozilla)]

#35, I wouldn't use a recurring task for something that has to be done that way, I'd use a recurring event. That way, you're dismissing only the exact instance. I use tasks for things where there's no concept "catching up." Think of a task to remind you to take out the garbage every night. If you're not home and miss a night, you don't have to take it out twice the next night.

Now, I realize that it doesn't give you a nice checkbox (and there may be other implications that I don't use or know about), but using events, each one will bother you until you dismiss them (rather than snooze).

Perhaps there should be two types of tasks, one for things that need to be "caught up" and one for things for which that concept means nothing. Or events could be augmented to supply some of the functionality for which people want tasks.

[Jonatan Cloutier (jonatan-cloutier)]

(In reply to comment #37)
> #35, I wouldn't use a recurring task for something that has to be done that
> way, I'd use a recurring event. That way, you're dismissing only the exact
> instance. I use tasks for things where there's no concept "catching up."
> Think of a task to remind you to take out the garbage every night. If you're
> not home and miss a night, you don't have to take it out twice the next night.
>

I dont remember were it's was written (I think it's probably on the wiki) but task are mean to say "yea something has to be done" and event "yae there is something at that time" the main difference being if you happen to miss an event well to bad it's over now, but a task still has to be done.

but I agree with you that there is 4 types of task:
-the one that just have to be done
-the one that have to be done before a time
-the one that have to be done after a time
-the one that have to be done after a time but before another time

starting from there we might do (has first draft solution and form a user perspective, so there is nothing about storage):
-the one that just have to be done
   =CREATION
      no start date, no end date, impossible to be recurring
   =SHOW IN LIST
      always shown, up to when it's ticked
   =COMMENT
      a task that just have to be done cannot be recurring afaik in other case how would you place the second occurrence?

-the one that have to be done before a time
   =CREATION
      no start date, with end date
   =SHOW IN LIST
      always shown, up to when it's ticked or the end date is pass

-the one that have to be done after a time
   =CREATION
      with start date, no end date
   =SHOW IN LIST
      show from start date to when it's ticked

-the one that have to be done after a time but before another time
   =CREATION
      with start date, with end date
   =SHOW IN LIST
      show from start date to when it's ticked or the end date is pass

then how to show it in the task-unifinder when showing 'all task' is the same as showing all event in the event-unifinder, I think the solution was to set a limit of occurrence shown. so use the same logic than event, I don't know what problem would come from there

now about the concern here I would say that as a user I would like to have the time of when I did the task so every time the I tick a task it must do a special instance and add to it the finish date.

from there doing a special instance for a task that has not been done but the next one yes is not a problem

so now in a developer perspective when ticking a task I would do:

   while this task is not the first instance
      do a special instance of the task that is not complete

   do a special instance of the task that is complete with it's finish date
   change the first instance date of the recurring task to the next occurrence

I don't know if it's cover all the possibilities of the problem but I think it's a good way of resolving the bug.

[bvdbos (bvdbos)]

(In reply to comment #11)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=373775#c29 for a possible
> resolution.

bug 272775 comment 29 says this bug should be resolved first. bug 438310 is related.

I think for unbound tasklists (no start and end-date) only the masteritem should be shown. For date-bound taskslists the recurrences within the date-range should be shown. The today-pane has a tasklist which is by definition bound to a range.

[Matthew-mecca (matthew-mecca)]

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.

[Matthew-mecca (matthew-mecca)]

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.

[Matthew-mecca (matthew-mecca)]

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

[Matthew-mecca (matthew-mecca)]

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

[Matthew-mecca (matthew-mecca)]

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

[Matthew-mecca (matthew-mecca)]

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

[Jane-2494 (jane-2494)]

Cool!!

[Philipp-bugzilla (philipp-bugzilla)]

(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.

[Ssitter (ssitter)]

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

[Matthew-mecca (matthew-mecca)]

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.

[Thomas Edwards (tom-rb-edwards)]

Nice one!
How do I apply this patch?

[Ssitter (ssitter)]

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

[Thomas Edwards (tom-rb-edwards)]

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.

[Artisticcheese (artisticcheese)]

This shall be marked as higher priority then normal.

[Matthew-mecca (matthew-mecca)]

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.

[Chuckc (chuckc)]

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.

[Wtarrasque (wtarrasque)]

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?

[Philipp-bugzilla (philipp-bugzilla)]

(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, ...

[Philipp-bugzilla (philipp-bugzilla)]

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.

[Philipp-bugzilla (philipp-bugzilla)]

>+ // 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.

[Matthew-mecca (matthew-mecca)]

> 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.

[Matthew-mecca (matthew-mecca)]

Created an attachment (id=429933)
Proposed Patch v4

Patch with requested fixes

[Philipp-bugzilla (philipp-bugzilla)]

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

[Ssitter (ssitter)]

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

[bvdbos (bvdbos)]

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).

[admiralnemo (admiralnemo)]

(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.

[LanceHaverkamp (lance-thehaverkamps)]

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

[Philipp-bugzilla (philipp-bugzilla)]

The cake is a lie.

[Cmichaelis (cmichaelis)]

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. :)

[Ssitter (ssitter)]

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

[Philipp-bugzilla (philipp-bugzilla)]

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.

[Matthew-mecca (matthew-mecca)]

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

[LanceHaverkamp (lance-thehaverkamps)]

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

Thanks very much!

Lance

[Philipp-bugzilla (philipp-bugzilla)]

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.

[Matthew-mecca (matthew-mecca)]

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

[Chrisb-whitehorsepark (chrisb-whitehorsepark)]

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

[LanceHaverkamp (lance-thehaverkamps)]

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?

[Philipp-bugzilla (philipp-bugzilla)]

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.

[Philipp-bugzilla (philipp-bugzilla)]

Marking FIXED by bug 350174.

[Ssitter (ssitter)]

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