How to iterate the objects under the promotion Workflow?

[lnunes]

Hi all.

I have this need to, after promotion request is done, create a new iteration for all promoted objects.

The objective here is to keep an iteration at the promoted state on the object history, even if the object is demoted, modified by set state.

Let´s say MFG users can´t see InWork objects, so we use to promote the objects to Proto. when this objects is required for a change, we set state back to InWork. At this moment, MFG users can´t see it anymore, but they should be able to still access the object at the moment it was defined as "Proto".

Actual scenario:

InWork 2.3

--> Promote to Proto

Proto 2.3

--> Set Sate InWork

InWork 2.3

Objects history will show only IW 2.3 iteration

Desired:

InWork 2.3

--> Promote to Proto

Proto 2.3

Proto 2.4 (if necessary)

--> Set Sate InWork

InWork 2.4

Object history will show

Proto 2.3

InWork 2.4

[TomU]

I think the more standard process would be to create a new revision, not a new iteration.

InWork 2.3

--> Promote to Proto

Proto 2.3

--> Revise to 3.x (automatically at InWork)

InWork 3.1

Object history will show

Proto 2.3

InWork 3.1

[lnunes]

Hi Tom, This is not the case for our organization, because the related process will be happening during an ECN.

So while designers are working in their CA, they need to collaborate to MGF their change before finish the task.

With this concept, MFG will also be able to see the objects after CA is done, because the UnderReview will use a latest iteration, so MFG can see latest released iteration objects as follow relevance order:

obsolete

released

proto

[TomU]

You could configure the permissions so that certain groups are allowed to check out and check in at "In Work" and other groups are allowed to check out/check in at "Proto".  Would that work with your business processes?

InWork 2.3

--> Promote to Proto

Proto 2.3

Proto 2.4 (if necessary)

Proto 2.5 (if necessary)

--> Promote to Released

Released 2.5

Object history will show

Proto 2.3

Proto 2.4

Proto 2.5

Released 2.5

To generate the 2.4, something needs to actually be checked out and checked back in.  You probably could write workflow code to force this to happen, and maybe even set state back to "In Work", but then you will have multiple "released" objects (at "Proto") inside the same revision.  This seems like it could cause issues...

[lnunes]

not a option either Tom.

Obsolete, Released and Proto states are considered immutable. Any change need to be done using InWork state.

Also, is not efficient to have someone doing Check out/ Check in just to keep the iteration at history.

[bsindelar]

You are correct that the "Iteration History" will only show as you explained in your "Actual Scenario".  However, have you looked at the "Maturity History" of the object?  This should show the changes in lifecycle states as well.

[lnunes]

Bob, I am afraid the maturity history is not considered for the users visibility, so it means, the MFG group will not be able to even report that the object exists if it have not a single iteration at Proto...

[bsindelar]

The maturity history does not show in the OOTB "History" tab (colored blue), but if you add a custom tab (colored gray) you can select it in the Customize drop-down, under the "History" section:

[lnunes]

I understand that, but MFG group can´t access, or even search, the object at InWork, so they will never be able to reach the Maturity History.

That´s why I am looking a way to create an iteration of the object when it reach Proto state, from promotion workflow..

[bsindelar]

Ahh I understand now.

Assuming that MFG group has Windchill user accounts, does it make sense to update the ACLs to grant these users read access to the objects?  Or is there a specific reason they do not have access?

[lnunes]

very specific reasons, so Engineers define when it is able to be seen by MFG

[lnunes]

I got the expression bellow, fixed some, but it is returning the error:

WfExpression_l.java:36: error: cannot find symbol

  wt.fc.PersistenceHelper.manager.refresh((Persistable) promotionObject);

                                          ^

  symbol:   class Persistable

  location: class WfExpression_l

WfExpression_l.java:37: error: cannot find symbol

  wt.fc.PersistenceHelper.manager.save((Persistable) promotionObject);

                                       ^

  symbol:   class Persistable

  location: class WfExpression_l

Note: WfExpression_l.java uses unchecked or unsafe operations.

wt.fc.QueryResult promotionObjects = wt.maturity.MaturityHelper.service.getPromotionTargets((wt.maturity.PromotionNotice) primaryBusinessObject);

wt.pom.Transaction tx = new wt.pom.Transaction();

while (promotionObjects.hasMoreElements()) {

  try {

  tx.start();

  Object promotionObject = promotionObjects.nextElement();

  promotionObject = wt.vc.wip.WorkInProgressHelper.service.checkout((wt.vc.wip.Workable)promotionObject, wt.vc.wip.WorkInProgressHelper.service.getCheckoutFolder(),"Automatic checkin as part of Promotion Notice process.").getWorkingCopy(); 

  wt.fc.PersistenceHelper.manager.refresh((Persistable) promotionObject);

  wt.fc.PersistenceHelper.manager.save((Persistable) promotionObject);

  wt.vc.wip.WorkInProgressHelper.service.checkin((wt.vc.wip.Workable)promotionObject, "Automatic checkin as part of Promotion Notice process.");

  } catch (wt.util.WTException wte) {

  System.out.println("Error reported in Promotion Notice : " + wte.toString());

  } finally {

  if (tx != null) {

  tx.rollback();

  System.out.println("Transaction to update item in Promotion Notice rolled back");

  }

  }

}