GTG

Removing a task should remove its sub-tasks

Bug #345504 reported by Raphaël Hertzog
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GTG
Fix Released
Low
silentStatic

Bug Description

When I remove a task with sub-tasks, the sub-tasks are kept and replace the removed task. That's counter-intuitive. Sub-tasks should be removed together and the confirmation screen should warn that the X sub-tasks will also be removed.

Related branches

Revision history for this message
Bertrand Rousseau (bertrand-rousseau) wrote :

I guess it should be proposed to the use to remove the subtasks as well by default.

Changed in gtg:
importance: Undecided → Low
milestone: none → 0.2
status: New → Confirmed
Revision history for this message
Zach Shepherd (eightball1989) wrote :

I believe that "Delete" and "Delete & Delete subtasks" should be separate actions. If I decide to change the way I've structured a big task, I should be able to delete just specific tasks that may be parents of sub tasks.

If I start with:
A
 - B
  - C
  - D
 - E
  - F

It should be (and currently is) trivial to arrive at:
A
 - B
  - C
  - D
 - F

The ability to go straight to the below should be a new feature, not a change to the above feature:
A
 - B
  - C
  - D

Revision history for this message
Raphaël Hertzog (hertzog) wrote : Re: [Bug 345504] Re: Removing a task should remove its sub-tasks

On Wed, 24 Jun 2009, Zach Shepherd wrote:
> I believe that "Delete" and "Delete & Delete subtasks" should be
> separate actions. If I decide to change the way I've structured a big
> task, I should be able to delete just specific tasks that may be parents
> of sub tasks.

You have drag and drop to restructure. Not removing sub-tasks is
counter-intuitive. Doing what you want is "reparent task" + "remove task"
and should not be "remove parent task".

Cheers,
--
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/

Revision history for this message
silentStatic (kjmikkel) wrote :

I have been hacking at it, and it seems that a simple change in task.py's delete function would fix this. Instead of calling

task.remove_parent(self.get_id()) (line 483 I think)

for each subtask, my change calls

self.req.delete_task(task.get_id())

which seems to do the trick. From what I can read from the code this is not a breach of the architecture, though I might be wrong. The net result is that all subtasks (as well as their subtask and so on) to the deleted task are deleted.

So if we had
1.
A
 - B
  - C
  - D
 - E
  - F

Then deleting E would leave us with
2.
A
 - B
  - C
  - D

And if we deleted A (in either 1 or 2) there would be no tasks left.
Unless there are any objections I would like to test it a bit more, and then try to push it to a branch.

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

If we go this way of removing the children, it should be clear in the warning dialog and, in this very same dialog, we should list the tasks that will be permanently deleted.

Revision history for this message
silentStatic (kjmikkel) wrote :

I agree, but it seems that the confirmation widget is created by gtk.glade.XML (the creation is line 1237 in browser.py), and I have not been able to change the text through the code. My experience with pygtk is limited, so if there does exists a way to alter the text in a dialogue after it has been created, please do tell.

My best judgement tells me that recoding the warning dialogue system, or creating an exception just for this, is the wrong answer - and so, while I could change the message to explain to the user that s/he would delete each task, and all their subtasks, I would not be able to specify the names of the tasks that are going to be deleted.

Revision history for this message
silentStatic (kjmikkel) wrote :

I have created a possible fix and pushed it to the kjmikke\gtg\removeSubtasks branch (revision 325).

Changed in gtg:
assignee: nobody → silentStatic (kjmikkel)
status: Confirmed → Fix Committed
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

Please don't change the status to Fix Committed unless the fix is commited to the Trunk

Changed in gtg:
status: Fix Committed → In Progress
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

Merged with rev. 359

Thanks for that. I corrected some stuffs, please test !

Changed in gtg:
status: In Progress → Fix Committed
Changed in gtg:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.