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

dritter-3 · ‎May 16, 2019

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.

BjoernRueegg · ‎May 16, 2019

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.

JeffZemsky · ‎May 16, 2019

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

BjoernRueegg · ‎May 16, 2019

@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:

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

Or am I wrong?

JeffZemsky · ‎May 16, 2019

@BjoernRueegg

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.

BjoernRueegg · ‎May 29, 2019

@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.

JeffZemsky · ‎May 31, 2019

@BjoernRueegg 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.

gprajeesh77 · ‎Jun 22, 2019

Hi @JeffZemsky ,

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

Thanks

Prajeesh Kumar

dritter-3 · ‎Oct 17, 2019

"lock" would work in Change Objects,

but "unlock" is not possible afterwards for Change Objects, because the API is only written for Promotion Requests.

@JeffZemsky should I update the description or open a new product idea? Because "unlock" after the "lock" is not a "current functionality".

JeffZemsky · ‎Oct 18, 2019

@dritter-3 Change Notice / Change Task are supported already with the Review / Refine Transitions. Review can be used to set Resulting objects to a Read only state and Refine can be used to set them to an editable state to make corrections, do some work. They can then be set back to a read only state using the Review transition.

You can should information here:

Review and Refine Transitions