It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×10,914
×411

question asked: Oct 14 '15, 2:53 p.m.
question was seen: 3,447 times
last updated: Dec 04 '15, 4:01 p.m.

Related questions

How Can I Suppress Operational Behavior During Template Instantiation?

0
Nate Decker (378●1●47●61) | asked Oct 14 '15, 2:53 p.m.

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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
sam detweiler (12.5k●6●195●201) | answered Oct 14 '15, 3:02 p.m.
no. there is no ability to detect  template vs normal WI instantiation.

the only way I have been able to handle this is to disable the advisors and particpants during that process.
ugly and hard.

easiest way was to provide a new role that uses the templates and not configure the extensions for that role.
Comments
Nate Decker commented Oct 14 '15, 3:14 p.m.

Thanks for the response, even though that's not the answer I wanted to hear. The fact that it comes from you makes me super pessimistic that I'll find a way.

I had considered asking the end users to use a special "templates" role or something like that, but I was skeptical that such a request would be well-received. I expect I would get pushback from people who wouldn't want to juggle user roles. It would also cause issues if people forgot to set the role back again.

I guess I'll do a couple of experiments and see if inspiration strikes somehow.

Nate Decker commented Oct 14 '15, 4:12 p.m.

One thing I've noticed is that when the template is being instantiated, one of the save parameters is "com.ibm.team.workitem.common.internal.ignoreCommentUpdates". I didn't see this same save parameter while creating work items manually. Instead, I saw "com.ibm.team.workitem.common.internal.updateBacklinks".

I don't know if this difference is consistent or not or under what circumstances one is present versus the other. Have you looked into this previously?

sam detweiler commented Oct 14 '15, 4:36 p.m.

I had not.  Without documentation I would be unwilling to depend on this.

0
permanent link
Nate Decker (378●1●47●61) | answered Dec 04 '15, 4:01 p.m.

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

Register or to post 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.