Using Resolution field for non-closing State
Hi,
I've received several requests for a Blocked state from my team with different examples of situations where it's needed. I was thinking of adding a Blocked state to the Workflow and using the Resolution field to list the reasons why it would be Blocked that the user could choose from. Is this an ok way to use the Resolution field considering it isn't a closing state or should I use a new field to capture this info? |
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 28 '11, 9:51 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Normally, one uses the "blocked by" relationship to indicate that you
are blocked by something. The advantage of the relationship is that it tells you what you are blocked by, and you can automatically tell when you are unblocked when the work item you depend on is transitioned to "complete". But you certainly could add a Blocked state to your state values as well. Cheers, Geoff On 4/27/2011 2:23 AM, miwalker wrote: Hi, |
Normally, one uses the "blocked by" relationship to indicate that you Hi, Thanks Geoff, We do use the Blocked By relationship to some degree, but there are instances where items are blocked on something that isn't represented by a work item and I don't think I can convince them to create a new work item each time this occurs. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
This is an old question and probably no longer of interest to you. That being said, I thought I would weigh in on this since this forum is not only for answering questions of the original poster but also as a reference to others.
If you use a Resolution value for this purpose, then you have to either:
1) Allow the resolution to be displayed through additional states so that you can display those values. You might also want to be able to change them.
2) Alternatively, if the resolution field is only available on the work items while they are in the "Blocked" state, then that has to be the only time anyone cares to see/use that value.
Basically, the problem with the resolution versus other attributes is that it is only visible and modifiable during certain states. It's possible you may want to see or use that resolution value in states beyond the 'Blocked' state.
Incidentally, we also implemented a 'Blocked' state in our own implementation, but didn't provide resolutions. We assume the end-user will document the reason for the blockage in the description or some other text field of the work item.