GNOME Bugzilla – Bug 303251
Include WBS number in predecessor drop down list
Last modified: 2010-01-16 18:05:27 UTC
Version details: Fedora Core II When adding a predecessor to a task, the drop down list of tasks (in the 'Add Predecessor' dialogue box) lists the task names, but not the WBS associated with each task. This makes things tricky if there are subtasks in the project with duplicated names, for example: 1 Bake cake 1.1 add flour 1.2 add sugar 1.3 add milk 2 Make cup of tea 2.1 add water 2.2 add sugar 2.3 add milk If adding the milk to the cup of tea required the sugar to be added first (this is important to some people! :-), then I go to the 'Add Predecessor' dialogue and I have to decide which 'add sugar' task I should chose. If the task names were preceded by the WBS, then I know for sure that I want to select '2.2 add sugar' and not '1.2 add sugar'
What's worse is that the selection actually just picks one for you, no matter which you pick. (ie. you'd always end up with '1.2 add sugar', no matter which 'add sugar' you really clicked on).
I was just about to submit this as a bug, but it seems someone else has found it a while ago. It should be noted that Planner 0.14.1 still suffers from this same issue. While the above explanation is fairly clear, here is an even easier method to reproduce this bug: 1. Start a new Planner project 2. Create a task 'A' 3. Create a task 'B' 4. Create two subtasks under 'B', both called 'C' Your tree should look like this: 1 A 2 B 2.1 C 2.2 C 5. Right-click on 'A' and select 'Edit Task...' 6. Select the 'Predecessors' tab 7. Click 'Add', and select the second 'C' task (2.2). [As a side note, if you click the drop-down list button again, you'll notice the first 'C' task (2.1) is selected, not the second.] 8. Click 'OK', then 'Close', and Planner will have mistakenly linked the 2.1 C task to 1 A instead of 2.2 C as you have specified. Since this is a true bug in Planner, I think the severity for this issue should be changed from enhancement to normal.
My company is starting to use planner for all of our projects. The template for our project plan is 450 tasks long. It is critical for us to have WBS included in the "Add Predecessor" dropdown menu.
Likewise, having the drop down having the current task selected so that you start in the current location, since you will typically make a nearby task a predecessor.
I think the criticality of this bug should be changed. A status NEW since 2005 and a bug marked as Importance: Normal enhancement will not get processed I guess. That's not a Normal enhancement, that's a normal feature that everyone should expect from a project management software. So in few words : can we change the criticality of this bug or should we start a new one ?
I'm no developer, but by quickly browsing the source code it seems that a task property doesn't even include WBS code. So I guess that introducing the WBS instead of name in the "predecessor" menu could be problematic. So in the meantime, the only work around I can think of is to start the name of the task with the WBS number. Could be problematic if you want to move the tasks around, on the other hand that will force us to work on paper first, get ll the actions and then typing them in. If need be we can hide the WBS column in the different views. That's an ugly work around, but that works :)
(In reply to comment #5) > I think the criticality of this bug should be changed. > A status NEW since 2005 and a bug marked as Importance: Normal enhancement > will not get processed I guess. NEW means that the bug has been confirmed. Enhancement means that this is a feature request and not a bug. You might want to read https://bugzilla.gnome.org/page.cgi?id=fields.html#importance to understand current priority of this bug. > So in few words : can we change the criticality of this bug or should we start > a new one ? Start a new one? What do you mean exactly? Filing a new report with the same request will only result in a duplicate that the devs will have to close. (In reply to comment #6) > That's an ugly work around, but that works :) We're not really interested in workarounds and would rather have a sustainable solution.
I should close the other bug as a duplicate of this one, however the other one has a patch, hence doing it this way. *** This bug has been marked as a duplicate of bug 604169 ***