Using lifecycle java procedures Vs auto workflow tasks

Hi,

We have requirements to modify the permissions on the document as it moves in the workflow. In the begining reviewers, approvers, authors have read access. If it is rejected then the author has version access. There are 2 ways of doing it one as a post java procedure on the lifecycle state or as a auto workflow task that calls a java method. I think doing it as a auto workflow task will create workitems. Depending upon how many times it gets rejected it will create workitems and if the workflow audit is on it the tables are going to grow where as if implemented as lifecycle java procedure it may be beneficial.

Am I correct in my thinking? Are there more ways of implementing it? Please give me the pros and cons and some advise as the best approach to do it.

We are still on 5.3 SP5 of content server, DFC 5.3 SP5 and would like the best approach as soon we would upgrade to D6.5

Thanks

Find more posts tagged with

Comments

JosePGisone

It sounds like you have both a workflow and a lifecycle to deal with in this scenario.

I would recommend an alternative approach that might save you from writing code.

How about when a task gets rejected, instead of the document being demoted to a previous state, it gets promoted / suspended / attached to a different, later state? In that subsequent normal state (or suspension state), assign a new / different ACL that grants the authors VERSION access.

Play around with those possibilities and you should be able to come up with a solution that does not require coding, and in that way you avoid potential changes to your code necessary when upgrading.

If you still must do it via code, I would recommend you wait until after you upgrade to 6.5, to avoid any potential changes.

Learner

thanks Jose for your helpful reply.

I forgot to mention one more part that there is only one author that is set in an attribute value and is resolved as an alias value in the TBO.