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.
The pros:
- I’m relying on existing features of Team System, it’s supposed to make the enhancement tighter with the original software.
- I thought it would be easier to code it that way… Well, until I had to code it!
The cons:
- It turned out that the Links of type “Work Item” are bidirectional, and then automatically created on the opposite way when you create a new link. This is a REAL PAIN for the implementation, because you constantly have to SyncToLatest() the opposite Work Item after creating a Link. And looks like it’s not always working: there are some times when I have exceptions raising because of my Work Item not up to date with the server.
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…
- There is no order between siblings, not even a chronological one. I first thought that the order will be chronological, but it turned out it has no sense at all (on a functional point of view). And my teammates yell at me “why the order changed suddently!!!”
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! 🙂
Profiles
