Closed Bug 373775 Opened 17 years ago Closed 13 years ago

Marking repeated task complete marks all instances of the task

Categories

(Calendar :: Tasks, defect, P2)

Product:
Calendar
Component:
Tasks
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: neoscona, Unassigned)

References

Details

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.


Duplicate of Bug 360356?
This looks like duplicate (or subtask) of Bug 155889.
Or it is a duplicate of Bug 155889.
Oops, meant to say:
Or is it a duplicate of Bug 350174.
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [qa discussion needed]
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.
Status: UNCONFIRMED → NEW
Depends on: 155889
Ever confirmed: true
Whiteboard: [qa discussion needed]
Flags: wanted-calendar0.8?
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.
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.
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
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?
Depends on: 350174
No longer depends on: 155889
Flags: wanted-calendar0.8- → wanted-calendar0.9?
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).
Flags: wanted-calendar0.9? → wanted-calendar0.9+
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?
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. 
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 :)
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 :-)



(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?
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... :)
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.
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.
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"!
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"!
(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.
I second the motion. Please give this bug a higher priority: recurring tasks are unusable at present.
Flags: wanted-calendar0.9+ → wanted-calendar1.0+
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.
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.
Flags: tb-integration?
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!
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.
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.
Flags: tb-integration? → tb-integration+
Priority: -- → P2
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.
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>
#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.
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
#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.
(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.
This shall be marked as higher priority then normal.
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?
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
You need to log in before you can comment on or make changes to this bug.