My team came up with a request that looked at first « easy to code » but which turned out to be a real pain: managing order in siblings.
As I wrote in a previous post, I was using the Work Item’s Links (to link a son with its father) and a custom field “ParentWI” to handle the Hierarchy.
This issue is emphasized by the fact that you CAN’T merge Work Item: I you made changes locally and the Work Item was changed (due to the bidirectional link creation, for instance) by the time you save it, it throws you an exception…Not very handy or easy to encounter…
I came to the point that I had to implement hierarchy in a different way: forget about the Links, this is just a nightmare for WI Hierarchy and I can’t really see the advantages for the price I pay to use them.
The solution was not complicated to find: add two more custom fields.
“FirstChildWI”, it contains the ID of the first child of the Work Item.
“NextWI”, it contains the ID of the next sibling.
I don’t need a “PrevWI” kind of field, parsing backward is not very useful, and I can still do it without it.
Another solution would have been to create a “ChildrenWI” custom field of type String that references all the children in a given order. But I assumed (maybe I’m wrong) that the String type has a limited size, and I wouldn’t want to limit the count of children.
So here I am, three custom fields for the hierarchy, no more Links to handle, a simplified saving process, and I still kept the ability to create new Work Items in a hierarchical way WITHOUT saving them right away (which lets the user the possibility to “delete” the Work Item if needed).
The user has the ability to reorder its Work Items, life is good! 🙂