Tasks should also be able to "Repeat"

RESOLVED WORKSFORME

Status

enhancement
RESOLVED WORKSFORME
17 years ago
10 years ago

People

(Reporter: Peter, Unassigned)

Tracking

Details

Attachments

(4 attachments, 1 obsolete attachment)

Task should also be able to "Repeat"

Need a "Recurrence" tab in the "Create New Task" dialogue (just like for Events).
Keywords: mozilla1.1
Summary: Task should also be able to "Repeat" → Tasks should also be able to "Repeat"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.1
Status: NEW → ASSIGNED
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 nobody@mozilla.org in
case someone else wants to take it on.
Assignee: mikep → nobody
Status: ASSIGNED → NEW
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.
Assignee: nobody → 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.
- 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.
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
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.
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.
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 :-\
Attachment #162451 - Attachment is obsolete: true
(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. :-(
Blocks: 225711
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.
Component: Sunbird and Calendar-Extension Front End → Base
QA Contact: colint → base
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
(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.)
Duplicate of this bug: 376657
(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.
Component: Internal Components → Tasks
QA Contact: base → tasks
Repeating tasks are possible by now. Nominating for WORKSFORME.
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).
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?
Whiteboard: [qa discussion needed]
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [qa discussion needed]
Blocks: 373775
No longer blocks: 373775
You need to log in before you can comment on or make changes to this bug.