Bugzilla – Full Text Bug Listing
| Summary: | subtasks can get more than one category assigned | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jörg Thönnes <jtk499> | ||||||
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> | ||||||
| Status: | CLOSED MOVED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P2 | CC: | steffen.pingel | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jörg Thönnes
Created attachment 195989 [details]
Screen shot with three categories selected
Created attachment 195991 [details]
Screen shot of Task List (Categorized view)
Here you can also see that task 5529 is a sub-task of task 5526 (which has no special features).
And the task is listed in all three categories.
In addition, the Tasktop working sets also honour this. The task appears in three sets with disjunct categories.
The Trac task with this special behaviour is a sub-task of another trac ticket. Tasktop Associations: The parent task is not recorded in this section (should be). Is there any way I could export this task in order to attach it here? At the moment, I would not like to change too much in order to keep this task as reference. Waiting for further instructions to proceed... Thanks for the screenshots, Joerg. It's not necessary to attach the task. I'll try to reproduce locally with the given information but it would help if you have any other hints how the task was assigned to the categories. (In reply to comment #4) > Thanks for the screenshots, Joerg. It's not necessary to attach the task. I'll > try to reproduce locally with the given information but it would help if you > have any other hints how the task was assigned to the categories. OK, I cannot recollect fully, but I created this Trac task using the "Create a new sub-task" button. Normally, I select the category immediately at creation or not too much later, so I think the sub-task was created from a Trac task which already had a category set. Looking more closely on the second screen shot reveals that the given task 5529 is a sub-task of 5526 belonging to "5:Later" and 5527 belonging to "1:NA*". Somehow the category is inherited from the parent tasks. In addition, I can set a 3rd category. (In reply to comment #6) > Looking more closely on the second screen shot reveals that the given task 5529 > is > a sub-task of 5526 belonging to "5:Later" and 5527 belonging to "1:NA*". > > Somehow the category is inherited from the parent tasks. In addition, I can set > a 3rd category. Now I removed the dependency on the 5527 task and the category "1:NA*" is gone. Steps: 1. Create two categories A and B 2. Create a task, assign to A 3. Create a subtask The editor shows the subtask as Uncategorized but the context menu now shows that the subtask is in A. Other steps: 1. Add repository task to category A 2. Create new subtask 3. Submit subtask 4. Assign subtask to category B The subtask now shows two categories, A and B. This needs to be fixed. Since I use categories to move tasks from one Task Workings set (e.g. Next Actions) to another (e.g. Waiting For), this is quite annoying. Instead of specifying the category on the sub-task, where it is "added" to the category inherited by the parent task, I have to change category on the parent task. The intended work flow is not clear here. Any plans how it _should_ work? Hello Steffen, do you see any easy way to correct this? As explained above, I implemented my GTD workflow based on the categories. But bug prevents me from correctly assigning categories to sub-tasks. I haven't had a chance to investigate a fix. I'll schedule the bug for next week but I can't promise that I'll get to it. OK, thanks. For me this is a constant annoyance. I will explain you why: Implementing the GTD (Getting Things Done) principle I manage tasks in different categories "NA" (Next Actions) and "W/F" (Waiting For). So it may happen that the main task should be in "NA", but one of the sub-task is in "W/F" because I am waiting for other peoples work. This cannot be implement with the current behaviour. So finally I end up having all sub-tasks in "NA". In some other comments I also said, that JIRA "Relates to" links could be also implemented as sub-tasks. Possibly, I was wrong there. Steffen, do you see any chance to get something useful checked-in for 3.7? Thanks, Jörg Another "real life" examples using JIRA: Consider you have the following task relations with two JIRA repositories: SUPPMACD-780 is a sub-task of SUPPMACD-762 SUPPMACD-762 relates to DEVTS-300 and DEVTS-365 DEVTS-300 relates to DEVTS-365 If you start at SUPPMACD-780 and "Set Category" shows to you that both "NA" and "W/F" are set, the big question is: What is the category of the "parent" task? You can identify the parent task by two properties: 1. It has only one category set. 2. If you change this category, the old category is unset. While sub-task have the properties 1. One or two categories may be set. 2. If you change the category, one category remains sticky (cannot be changed). So the quest for the parent task starts, finally ending at SUPPMACD-365. This is really painful, since the category of DEVTS-365 effectively forces all the other tasks to have the same one. I have a faint memory that I could change the behaviour of "linked" tasks for JIRA, so that only real sub-tasks take part in the parent-child-relation... Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |