How to use Precondition for Lifecycle to stop using lifecycl promote

Hello All,

I have requirement to block the lifecycle promote when already workflow is running on that document object. How can I achieve the same.

For example, I have document in which attached to workflow (this will attach policy/lifecycle) now we have some auto promote states in workflow and same time user also can perform promote the document to next state.

Is there any way in lifecycle, before performing promote check workflow already attached ? And throw user friendly error message lifecycle already attached to the workflow.

Find more posts tagged with

Comments

DCTM_Guru

Extend the manual promote action and in your precondition, run the query to check for the running workflow.

lastnitescurry

me thinks that would be a performance hog, as it would fire for each item listed in folder. Assuming we are talking about Webtop/WDK app, better to create a custom launch action,

e.g. LaunchComponentWithRunningWorkflowCheck

Extend the manual promote action and in your precondition, run the query to check for the running workflow.

Have you investigated "Entry Criteria" of the lifecycle itself? Have not played with it but looks like you could set a flag (x_promote_permitted) on the document as first step of Workflow, then in the "Entry Criteria" test for this flag.

DCTM_Guru

Brian is correct about the performance hit of using precondition. I was suggesting it since you have a simple requirement and custom precondition is simple (and fully supported) way to do this.

You can also customize the promote action class and check for the running workflow in there. If there is a running workflow, throw an exception and dont execute the rest of the code.

stephanemarcon

Hi,

I'd do it with either of the two folowing methods:

- creating a class for the lifecycle and testing Your condition in the userEntryCriteria method ( see http://www.bluefishgroup.com/library/2008/custom-java-lifecycle-modules/)

- creating a tbo on your type and overridding the doAttachPolicy method

- or making the change in the interface as suggested by Johnny but I would personnaly go for one of the above solutions, with a small preference to the lifecycle class which is the safets in terms of cross- clients context

Stephane