Bug 60558 - Feature Request: Update a todo's completion percentage when a sub-todo is completed.
Summary: Feature Request: Update a todo's completion percentage when a sub-todo is co...
Status: CONFIRMED
Alias: None
Product: korganizer
Classification: Applications
Component: todoview (show other bugs)
Version: 3.1.1
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 80828 111444 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-07-01 01:11 UTC by Anthony Valentine
Modified: 2010-01-15 01:05 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
first mockup (3.20 KB, application/octet-stream)
2009-03-01 13:10 UTC, Fredrik Klasson
Details
second mockup (2.08 KB, application/octet-stream)
2009-03-01 13:10 UTC, Fredrik Klasson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Valentine 2003-07-01 01:11:15 UTC
Version:           3.1.1 (using KDE 3.1.2)
Installed from:    Gentoo
Compiler:          gcc version 3.2.2
OS:          Linux (i686) release 2.4.20-gentoo-r2

It would be nice to have a parent todo's complete percentage be updated when it's sub-todo's are completed.
Comment 1 ieure 2004-02-04 02:38:54 UTC
Furthermore, it would be nice if they inherited the percentage as well.

e.g. you have a todo structure like this:

Complete Foo Project
+ Implement Bar component (80% complete)
+ Fix Bug #15 in Baz library (100% complete)

At this stage, 'Complete Foo Project' should have a completion of 90% (sum of child completion percents, divided by number of children)

Currently, the parent todo must have it's complete % updated by hand.
Comment 2 Philipp Berndt 2004-04-08 17:25:49 UTC
Yes, please!
"Complete" value of a todo should be the average of its direct sub-todos (children).
Only for leaves (todos without further sub-todos) the user should be able to set the "completed" value.
Comment 3 Reinhold Kainhofer 2004-05-03 18:51:52 UTC
On Monday, 03. May 2004 08:40, Michael J.Korman wrote: 
 > In my opinion, subtasks should be completely bound to the supertasks. 
 > Changing one should modify the other accordingly. 
 
 But then you can't have hierarchies any more where your supertask involves 
 more than each of the subtasks accumulated. E.g. take cooking a meal: 
 
 [ ] cooking dinner tonight 
 [ ] shopping: whatever you need 
 [ ] Ask for the time 
 [ ] Does your better half like the food? 
 
 Surely, you won't put in a subtask "[ ] cook the dinner", and you don't want 
 the task marked finished when you have checked everything before you do the 
 actual cooking. However, when you're finished with cooking, you just check 
 the superitem, and all subitems are also finished. 
 
 Another sitation in which you don't want the supertask to be bound to the 
 subtasks is if you categorize your todos visually: 
 
 [ ] KDE 
 [ ] KOrganizer 
 [ ] fix bug XXX 
 [ ] implement that new feature 
 [ ] Check if korg really crashes in that situation 
 [ ] KPilot 
 [ ] Conduit so and so does not behave. 
 
 The KDE, KOrganizer and KPilot supertasks should never be checked, because in 
 the future you'll have new items there. 
 
 Now, the latter case should probably be implemented via uncheckable entries in 
 the todo list, but that's not possible yet, so completely binding subtodos 
 with their supertodos is suboptimal. 
 
 Cheers, Reinhold 
 
Comment 4 Reinhold Kainhofer 2004-05-03 18:52:07 UTC
*** Bug 80828 has been marked as a duplicate of this bug. ***
Comment 5 Anton Markov 2004-10-30 01:37:53 UTC
A good way to do this would be to:

A) Distinguish between a to-do that depends on the sub-todos and one that simply organizes them like a filefolder (kindof like the current behaviour). This should address the concerns in comment 3.

B) Add an optional "weight" field to each sub-todo so that you could say:
 - Mid-term essay
  - Choose essay topic [5%]
  - Write essay [70%]
  - Revise [25%]
So then when you are done "Choose essay topic", "Mid-term essay" will be marked as 5% complete rather than 33%.
Comment 6 Reinhold Kainhofer 2006-11-02 19:08:54 UTC
Reassigning all KOrganizer bug reports and wishes to the newly created 
korganizer-devel mailing list.
Comment 7 Bram Schoenmakers 2006-12-23 21:07:29 UTC
*** Bug 111444 has been marked as a duplicate of this bug. ***
Comment 8 Fredrik Klasson 2009-03-01 13:09:55 UTC
I've thought of this a little and how about this solution:
How about changing the "[0 %|v] completed" for "top-level-todos" to something like in mockup.ui? (attachment follows)

Basically it's as suggested in #1 but with the option of retaining the present behavior (by defaulting to checked the current behavior would be preserved).

Another possibility would be to "flip the condition", and i.e. have the option "make dependent on sub todos", which could open up for more detailed options.
eg: mockup2 
The "no auto finish" could be that the parent todo isn't closed when all children reach 100% or that the progress is computed as:
 min( sum(sub-todo-progress) / number_of(sub-todos) , 99%)
ie, clamping it at 99% unless we manually complete the parent todo.

Personally I'm in favour of the first idea, since the second seems a bit overkill; at least for now.
I'm also thinking that if the parent todo is completed manually (i.e. checked of in the todo list) then the sub-todos should be completed to. Especially if the option exists to make the parent todo depend on the sub-todo's, since that implies that sub-todos have some relation to the parent (basically if the parent is complete iff all sub-todos are complete, it should mean that completing the parent should imply that all sub-todos implicitly have been completed (as a prerequisite)).
Comment 9 Fredrik Klasson 2009-03-01 13:10:29 UTC
Created attachment 31713 [details]
first mockup
Comment 10 Fredrik Klasson 2009-03-01 13:10:50 UTC
Created attachment 31714 [details]
second mockup
Comment 11 simply_bugz 2010-01-15 01:05:45 UTC
I'm now using korganizer Version 4.3.2 and I don't see an option for this anywhere. I wonder why this feature is not included? It also seems to be the only place which picked up this issue.

Here is what I hope for:

For some tasks I really would like to see overall progress, so I intuitively tried to find the option to bind progress to sub-to-dos.
I was expecting an option which would enable calculation of average progress and display in top-level to-do with read-only progress bar (so that I wouldn't mess up the sub-to-do's progress).
Weighted average looks useful as well. I imagine that by default all tasks have equal weight and if one is modified the remaining to-dos would equally split the the leftover weight in proportion; unless the weight on a particular to-do is marked "protected".

For example
--Change0: Freshly added to-do---
[]Project (completion 0%)
   [] Task1 (Weight 25%) (completion 0%)
   [] Task2 (Weight 25%) (completion 0%)
   [] Task3 (Weight 25%) (completion 0%)
   [] Task4 (Weight 25%) (completion 0%)

--Change1: set weight on Task2 to 40; and set some progress values---
[]Project (completion 33%)
   [] Task1 (Weight 20%) (completion 65%)
   [] Task2 (Weight 40%) (completion 20%)
   [] Task3 (Weight 20%) (completion 10%)
   [] Task4 (Weight 20%) (completion 5%)

--Change2 set Task2 protected and set weight on Task1 to 10---
[]Project (completion 29.5%)
   [] Task1 (Weight 10%) (completion 65%)
   [] Task2 (Weight 40%) (completion 20%) (protected)
   [] Task3 (Weight 25%) (completion 10%)
   [] Task4 (Weight 25%) (completion 5%)

Change1 demonstrates P=(p1*w1 + p2*w2 + p3*w3 + p4*w4)
Change2 w3 = w4 = ( 1 - (w1 + w2) ) / 2; here w1 was changed and w2 is protected

And if you don't touch the weights (e.g. Change0) they stay as w_n=1/n.

The above of course is just an option in the Edit dialogue: "Calculate progress from dependent To-Do items". When ticked it unlocks "Task proportion: ##%" and "[] Protect value"