Do not Modify the Triggering Element in an OperationAdvisor

Don’t modify the element that triggers your OperationAdvisor! The API is not designed to support that. You can do this in a participant.

Get a comprehensive overview of the rules and how this works in the Team Process Developer Guide.

I met with the work item team in Zurich two days before and we had some discussion about automation around work items in several areas. This lead to looking into the API for the extension point com.ibm.team.process.service.operationAdvisors and we found that the class providing this actually states that you should not modify the object that triggers the operation advisor.

The Wiki topic Process Execution of Operations also explains that, and why client side advisors and participants must not modify information in the repository.

See the documentation of com.ibm.team.process.common.advice.runtime.IOperationAdvisor below:

/**

* Operation advisors are run before an operation is invoked to decide whether

* or not the operation should be executed. Advisors check conditions and

* report problems via the collector they are given. If an advisor reports a

* serious problem with an operation, the operation will not be executed (though

* subsequent advisors may still be checked).

*

* Advisors may not make modifications to data which is persisted in the

* repository. Clients wishing to participate in operations by modifying data

* should implement an {@link IOperationParticipant} instead.

*

* Operation advisors are contributed on the client and server via the

* com.ibm.team.process.client.operationAdvisors extension-point and the

* com.ibm.team.process.service.operationAdvisors extension-point

* respectively.

*

Why is that important? For example imagine you have the intention to check for a work item state change, and you want to add approvals for specific state changes. You could use an operation participant for that as described in this post.

You could however also have the idea to do that in an operation adviser. If you do that, it violates the contract of the extension point. The extension point does not check that and it might actually work, but there might be ill effects or, if the extension point starts checking in the future, your extension might stop working.

One example where you might have ill effects is that the manipulation and save of the work item will not cause a second save and thus also bypass any other Advisor you might have in place. If you had an advisor that prevented approvals from being added to work items, it would not detect that change.

In general, if you want to modify data, use an operation participant.

Related Posts

RTC Update Parent Duration Estimation and Effort Participant

Resolve Parent If All Children Are Resolved Participant

A Create Approval Work Item Save Participant

Jazz.net article about creating operation Advisors