How Can I Suppress Operational Behavior During Template Instantiation?
![]() Background We have a follow-up action that sets an integer attribute in a work item based on the number of work items blocking it from closing. So for example, if a parent has 3 children and 2 of them are open, the parent's "Blocking Link Count" will be set to '2'. This feature is to facilitate querying for work items based on the status of multiple children. RTC natively doesn't allow you to write a query like, "Show me all work items where there are zero open children." Problem This operation behavior seems to be triggering during template instantiation but before the template finishes its process. The template sees that some of the work items in the work item set have been changed and throws a "Stale Data" exception which causes the instantiation to fail. Question Is there a way to code up my operation behavior so it can detect whether a work item save was a template instantiation action? For example, is the state set to "uninitialized" until the very last phase of template instantiation or something like that? Is there any flag or property I can read to allow the operation behavior to make an early exit? |
2 answers
![]() By way of follow-up on this question, I never did find a solution to detect whether the work item was being created by a template. Instead, I employed a logic test. I designed my operation behavior so that it would not execute if the work item had been created within the last 30 seconds and had an attribute value that was highly unlikely to be present unless the work item had been instantiated by a template. I figured this would allow enough time for most work item set templates to instantiate successfully. Due to the nature of this particular operation behavior, I decided that the only way the work item could get into a bad state is if a user created a parent work item saved that parent, and then unlinked the child from the parent again and saved the work item, then re-linked the child back to the parent again and save again all within 30 seconds of the parent's creation. This seemed like an unlikely enough scenario that I accepted that corner case. Obviously not all operation behaviors would be able to take advantage of similar logic rules, but this might be a viable workaround in at least some instances. |
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.