Restrictions on Revise

[BenLoosli]

Is there any place in Windchill where a restriction can be placed on an object's revise statsus?

Let me explain what I would like.

Everything is created at version A and the Design state.

When it is promoted, it is at the Prototype state.

We had an engineer do a revise to the version A parts, bottom up.

When he got to the top level, the revise caught some of the version B parts he had already revised and made them version C. I would like Windchill to block a part at the design state (other than version A) from being revised to prevent this from happening again. It is this possible with some preference or will I need custom code?

The same scenario is with a version 1 or higher object at the pre-release state.

[BjoernRueegg · Accepted solution]

That is defined in the lifecycle template. If you remove the revise tick from the design state, he won't be able to revise anymore. 

Unfortunately you probably need to reassign all the templates afterwards. But there is also a reassign lc shell utility.

[BenLoosli]

I looked at my Lifecycle and see what you mean.

I will have to experiment as there is 1 use case where we do need to revise in the Design state now.

In  most cases, we do initial releases as version Am but there have been cases where we have had to revise that the version 0 for the initial release, but this also requires a state change. I need to see if I can do the state change before I do the the revise. The issue I see without testing is that we do the revise in the workspace, then check in at version 0 and do the state change in a common space browser window

[MikeLockwood]

In my humble opinion, PTC has done MAJOR harm to PLM usage in Windchill in general by having the default BASIC lifecycle template allow Revise from In Work to In Work, and a very large number of Windchill systems  use either this or something similar.

If you set up the lifecycle template instead to require changing the state for the last iteration of each Revision before being able to Revise, it effectively "locks" that Revision from further change.  The Revise action then requires REVISE permission at the current state along with CREATE at the Resulting state, and can be controlled much better.  The state change can be via:

- set state (permission given at starting state)

- via Promotion

- via Change

If you combine this with a two phase approach (e.g. Rev 1, 2, 3... A, B, C...), then Revise to get from numbers to Letters and the Revise within letters can much more easily be controlled, ideally being aligned with initial release for production and changes after that.

Setting up the lifecycle transitions and related permissions is critical to the system - but a huge number of systems work in really odd ways, primarily (in my opinion) due to the bizarre defaults in Windchill.