WBS Common Team Workflows exports type incorrectly for old workflows.
Brought to you by:
ken_raisor,
tuma
Menu
▾
▴
#284 WBS Common Team Workflows exports type incorrectly for old workflows.
In v2.1, the Work Breakdown Structure's Common Team Workflows.
Exporting workflows created in older versions report the workflow's wbsNode type incorrectly as 'Code Inspect Task' instead of 'Software Component' as indicated and displayed on the screen. New workflows are reported correctly.
N.B. Displaying the type as a column would also help to find this issue in the future.
This is not actually a defect - just a misunderstanding in how the data model works.
If you place your mouse over a workflow node in the workflow editor, it will not tell you that the node is a "Software Component," as you claim above. It will tell you that the node is a "Workflow."
As you see in the XML file, all nodes have an inherent type such as "Software Component" or "Code Inspect Task." But this type is irrelevant for workflow model nodes with indentLevel 1. The user interface ignores the underlying node type when indentLevel is 1, and displays the node as a "Workflow" instead.
This allows a user to turn a workflow model row into a workflow definition just by unindenting it all the way to the left; you don't have to take an extra user-interface step of changing its node type. You might argue that code should alter the internal node type when this occurs; but that would prevent "unindent, then indent again" from being a no-op. As it stands, the pseudo-ignored node type has a minor purpose of deciding what type the node will be if you indent it, and thus preserving state when you've performed a sequence of unindent/indent operations that should be a no-op.
This behavior is unchanged for over a decade, so it has nothing to do with version 2.1 or whether your workflow was created with an older version. The differences you are seeing are only a result of whatever type the node had in the editor before you unindented it to make it a new workflow definition.
If you are reading the workflow XML files with another piece of software, that software should follow the same logic as the Workflow Editor: check the indentLevel of a node, and if it is 1, treat it as a workflow definition, ignoring the type attribute. If this logic is difficult for your external software to perform, consider using a simple XSLT transform to tweak the XML file to your needs on the way in.
As a follow-on, if your external software writes its own workflow XML files for use with the WBS Editor, it will be essential for you to follow a similar storage strategy regarding the type of top-level workflow nodes.
In particular, you must not write the string "Workflow" as the type for nodes with indentLevel 1. Doing so would create a situation where a person would indent a workflow node and it would still display the "Workflow" icon; then if the resulting workflow was applied to the WBS, they would see Workflow icons in the main WBS. This could lead to unforseen problems as the data/calculation models are not designed to handle this scenario.
Instead, if you write your own workflow XML files, use the type attribute to record a "fallback" type for the nodes with indentLevel 1. That "fallback" type should be one of the legally recognized node types, in either the Component or the Task categories. "Component" or "Software Component" would be good choices.