Adding a tag inconsistently affects subtasks

Bug #504409 reported by Matthew Rasmus on 2010-01-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Getting Things GNOME!
Kevin Mehall

Bug Description

Steps to reproduce:

1) Create a new task
2) Add any number of subtasks through the "insert a subtask in this task" button in the task editor (be sure not to edit or even open these subtasks in the taskeditor)
3) Add any number of subtasks through right click->Add a subtask.
4) Add a tag (preferably one with a color set for an easy visualization of what happens) to the task created in step 1 (through editing, or drag and drop in the bzr version)

Expected result:

The parent task should be tagged, while the subtasks remain untouched, or, at the very least, the subtasks should be effected consistently.

My result:

The parent task, along with any task created with the "insert a subtask in this task" button are all tagged. This only seems to work as long as a subtask is "fresh"--meaning, at no point has a taskeditor been opened for this task. It also doesn't work if GTG was quit and reopened before adding the tag.

Changed in gtg:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 0.2.1
Bryce Harrington (bryce) on 2010-01-07
summary: - Adding a tag inconsistently effects subtasks
+ Adding a tag inconsistently affects subtasks
Changed in gtg:
assignee: nobody → Kevin Mehall (kevin-mehall)
status: Confirmed → Fix Committed
Kevin Mehall (kevin-mehall) wrote :

Related question that may or may not deserve its own bug. It would be trivial to make this change.

Imagine a hierarchy of tasks

- Task A
     - Task B
     - Task C

Tasks A and B already have tag @foo. If A is then dropped on @foo, should Task C be tagged with @foo?

Currently, if all tasks are untagged, and A is dropped on @foo, B and C will get the tag as well. But A already has @foo, it will not recurse into subtasks.

Matthew Rasmus (mrasmus) wrote :

Well, now it _adds_ tags consistently (with one exception I'll get to), but it will not remove tags consistently--if any of the subtasks have been edited, the tag will remain (but this isn't true on a tag that hasn't been edited). Now, if a parent task contains edited subtasks, and you manually type in a tag, you'll end up applying a new tag for each letter that is entered (with results that look like @t @th @thi @this) in each of the edited subtasks (but it works fine in non-edited subtasks).

Also, this is my own personal preference, but I like the ability to apply tags to a parent task without affecting the subtasks. That's just me, though--that it works consistently is much more important than that. :)

Kevin Mehall (kevin-mehall) wrote :

The new subtask tagging scheme in r530 reverts the part that causes that regression. It also means that once the parent is closed, adding tags does not affect the subtasks.

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

Other bug subscribers