Showing results for 
Search instead for 
Do you mean 
Reply

how to map the name of the reviewer in a workflow to an itemrevision property

We need to map the reviewer in a workflow to a custom persistent property ( of the itemRevision.

 

It is possible to fill a custom property with the workflow handler "EPM-set-property".

using this handler with the following arguments works:

-props = wei4_ISSUED_BY

-values= TEST

-to_att_type = TARGET

-bypass

 

Now I need to replace the value "TEST" with the reviewer. I have tried several values, like:

  • ItemRevision.Job.SIGNOFF(SUPERVISOR).group_member.user.person.user_name
  • ItemRevision.Job.SIGNOFF
  • etc.

Maybe I need the options -from_att_type and -from_relation, but I do not know what values these options need to have (what is the reference of the workflow to the itemRevision, etc).     

 

Ps we use TC8.3.3.3

 

6 REPLIES

Re: how to map the name of the reviewer in a workflow to an itemrevision property

Hi,

 

Have tried with passing $REVIEWERS?

data types should match to set the property values.

Re: how to map the name of the reviewer in a workflow to an itemrevision property

Hi S6bnju,

 

Thanks for your response.

Yes tried $REVIEWERS, the value of the property now is $REVIEWERS. 

Also Tried $REVIEWER. same result.

 

Is there anyone who can tell me the relation between the itemRevision and any workflow which has ran on the ItemRevision?  

Re: how to map the name of the reviewer in a workflow to an itemrevision property

according to G-TAC it is not possible to fill an attribute with the name of user who has done the review (reviewer) by using EPM-set-property handler.

 

The only way to accomplish this is to write a custom handler.

Even in TC 10 it is not possible. There are several enhancement requests for this.  

 

 

 

 

Re: how to map the name of the reviewer in a workflow to an itemrevision property

I think we may be having the same problem. The user/reviewer/responsible_party is a value on the workflow object and not on the item revision object. On top of this, the EPM-set-property handler allows you to set a system property like $CURRENT_DATE, but I cannot get it to set the reviewer. For instance, I've tried $RESPONSIBLE_PARTY and just RESPONSIBLE_PARTY and neither worked. Instead, it will put the literal string, so it can't resolve dynamic partipants.

Re: how to map the name of the reviewer in a workflow to an itemrevision property

to creeljd, yes we have the same problem. I hope the changes according to the ER's will be implemented soon.

If you have another solution, please share.  

 

rgrds Tamara 

Re: how to map the name of the reviewer in a workflow to an itemrevision property

GTAC helped but I had to do all the ground work. The strategy is to use dynamic participants and resource pools in the assignment. There are two EPM handlers for this:


1) EPM-assign-responsible-party-dynamic-participant

2) EPM-assign-signoff-dynamic-participant

The reason for these two handlers is that the first one allows you to assign a resource pool having only a "single" user to PROPOSED_RESPONSIBLE_PARTY.
[cid:image002.png@01D158FC.F10D5240]

The second one allows you to assign a resource pool having "multiple" users to PROPOSED_REVIEWERS (note the plural on the dynamic participant name).
[cid:image003.png@01D158FC.F10D5240]

Note: GTAC suggested creating custom dynamic roles but these two OOTB ones do everything we required.

I created a Group/Role in the Rich Client called Change Group/Analyst. The original intent was to use $ANALYST but I found that this works best with a resource pool, resourcepool:Group::Role.

You may already be aware of this but this also means these assignments don't show up in your normal Worklist, the role user will have to subscribe to the resource pool (Tools > Resource Pool Subscription) by adding the Group / Role. The good news is that the user only needs to do this one time and the resource will always be there until they decide to remove it.

For the second workflow ...Analyst2, I simply added another user to the Analyst group. Of course once you do that then the first one workflow will fail since they both use the same resource pool. So ideally, you may want to create two separate roles to test this (e.g., AnalystSingle and AnalystMulti).

After submitting your business object to the workflow, the Condition task will start. Here, the process owner will click the Assign link to reassign it to Analyst/Group:

[cid:image001.png@01D158FB.14898F10]

Then go to the resource pool user's Worklist and signoff as Rework. That will send it to the rework user (tester1) who then signs off as complete and now....Drum Roll Please, it returns to the condition task but instead of going back to the process owner to reassign a reviewer all over again, it will return to the resource pool instead!

The net effect is, process owner assigns a reviewer only once and then it will always return to the resource pool for the remainder of the workflow.

Best Regards,

John D. Creel

FOR OFFICIAL USE ONLY - This e-mail and/or its attachments may contain ForeThought, Inc. proprietary information. Such proprietary information may not be used, reproduced, or disclosed to any other parties for any other purpose without the expressed written permission of ForeThought, Inc. Misuse or unauthorized disclosure may result in both civil and criminal penalties. If you have received this e-mail in error, please notify the sender by responding to the e-mail and then delete the e-mail immediately.