cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

"lock" transition can only be used in Promotion Requests but is also needed for other Change Objects

"lock" transition can only be used in Promotion Requests but is also needed for other Change Objects

The OOTB "lock" transition can only be used in Promotion Requests. Please implement it also for other Change Objects.

 

Goal:

Lock the edit of the resulting objects (WTParts, EPMDocuments, WTDocuments) as long as the Change Notice is in state "Under Review". That would force the user to do a "rework" so that the resulting objects are unlocked again and the process runs through all needed steps (validations, reviews, update attributes...) again.

7 Comments
Pearl

This would make it easier. To lock the objects is not very complicated but to put the object back to the state, where they were promoted, is not that simple. I wrote a small piece of code which will get the previous state before the lock state and demote it afterwards. This works very well, but is a small customizing.

Peridot
Status changed to: Current Functionality

Change Notice/Task supports Review/Refine transitions.  The Review transition supports setting the Resulting Objects to a read-only state.  The Review transition can set the Resulting data to an editable state (eg Rework) so that corrections can be made (and can then be set to the Review Transition)

 

Information can be found here

 

Change Management Transition

Pearl

@JeffZemsky Sorry, but I disagree. The Review/Refine works for an easy lifecycle. But not for a lifecycle like

Design->Prototype->Prototype in Change->Pre Series->Pre Series in Change -> Series -> Series in Change -> Phasout -> Obsolete -> Under Review

 

When you have multiple target states then it's easy to set it to Under Review. But when you do want to have a rework you don't know anymore, in which state the object needs to be demoted.

 

E.g. Object  has Series in Change -> target state= Series

When the object is being promoted to state Under Review to which state is the object afterwards being demoted? 

 

At the moment we have two possibilities:

  1. Customizing
  2. multiple review states: Prototype Review, PreSeries Review, etc..

Or am I wrong?

 

Peridot

@brueegg 

In a Change Task you can define a release Target (Transition) to allow the user to select it on any of the Resulting data.  This lets the user pick the target transition to release to.  Because of this one has several options for working with the Review transition

 

1) If you do not plan to use the Refine state you need only one "Review" transition.  One can setup transition rules to use the Review Transition to get to this state and then from the Review Transition you can define which Transitions it can go to which can be any of your target Transitions selected for the Resulting object.

2) A company might choose to have more granular review transition states if if helped from a business standpoint, but it is not required.

 

When using the Refine transition the same pattern would hold true.  Once set to the Review Transition it could then go back to the Refine Transition and the only transition from Refine might be back to Review.  As noted above the Review transition would know which Target state to go to for the release based upon the selection made for the Resulting data and appropriately defined Transition rules.

 

Assuming the case where one did not provide user selectable release target and had the lifecycle state shown above, this could would work, but one would be required to add a "review" transition and state to each phase of the "maturity" in the lifecycle.

 

 

Pearl

@JeffZemsky I'm in the middle of defining a new lifecycle with following states

Design -> Prototype in Change -> Prototype -> Series in Change -> Series -> Phaseout -> Obsolete -> Under Review

 

When a new Part (In state Design) is added to the change task the user needs to select a transition Prototype, Series or Obsolete (I created custom transitions for these states). He will complete his task and as soon he's finished, the part is being set to the "Under Review" state. 

 

The review in the change task selects then rework since something is missing.  So now is the question, how to get the part back to his first state "Design". The review state doesn't know where to put the part back. Or?

 

Let's do the exact same for a Series change:

The Part is in state Series and is being revised to "Series in Change". In this state the user can choose between Series and Obsolete. He chooses Series and completes his task. The part is also being set to state "Under Review". The reviewer selects rework. The part needs to be set back to "Series in Change". All other states would be wrong. 

 

Perhaps I'm completely wrong with this concept. Could you please share some slides or documents, where this refine and rework is being explained? The customization guide does have a chapter, but it is not clear, since some steps are missing there.

 

 

Peridot

@brueegg You are a little off on how the transitions can be configured.  After Liveworx I will post an example.

 

The solution you are asking can be configured.  One note I would recommend using a different state for rework during a change to make it more apparent to users that the item is not back in an open WIP, but rather being updated in the context of the Change.  eg something like REWORK or UPDATE versus the same state used for WIP during development.

Visitor

Hi @JeffZemsky ,

 

I am also working on the same model as @brueegg . I would lie to see your proposal on Transition

 

Thanks

Prajeesh Kumar