Windchill Revision Issue

[ptc-1763396]

I want to see if anybody has an aswer for my below issue:

I believe a setting in Windchill was overwritten on our last software upgrade allowing this to happen because this was never an issue in the past. To add to this, our admin person handling Windchill issues is no longer at the company. So I am trying to stumble through this.

Here is the issue:

Two users have the same file in their workspace. The file revision is A.1 User #1 bumps the rev to REV 1.1, makes changes and checks in the file into the Windchill Cabinets. User #2 (who still has the rev A.1 in workspace) now shows an out of date symbol in thier workspace for this file. User #2 makes modification to the A.1 and checks in the file as A.2 into the Windchill Cabinets. The system allowed this and didn't prevent the check in for an out of date file. The system is allowing separate sequential check in of Alpha revision and Numeric revisions- even though the icon in workspace showed out of date.

Reviewing the Revision/Iteration history shows: (earliest on top) Shows in chronological order

A.1

1.1

A.2

If a third person (User #3) opened the file - pulling what the system says is the latest Revision/Iteration - it pulls the 1.1

This issue only happens when two or more people have the same revision/iteration in workspace and one person bumps the file across the numeric/alpha threshold. It doesn't happen say from A to B or from 2 to 3. Only if going for example from D to 1 or 0.5 to A.

And you guessed it - we know this is happening because we had to untangle a big mess - and since duplicated it as a test.

Any ideas?

Thank you,

Clint

[GregoryPERASSO]

Hello Clint,

I'm not familiar with Revision schema where we can switch from Numeric to Alphabetical or vice versa.

But with the OOTB Alphabetical schema, windchill allow to modify a part from A.1 to A.2 by a user1,

even if a user2 have already revised in B.1 and is checked out and working on ...

each revision is a "standalone" workable instance. It permit , notably if you work with Config management (dated, lot, serial number effectivities ...)

to work in "parallel", on future enhancements of your product and control the release to production by effectivities

the "absolut latest" is the B.1. But the "good" revision for a specific need depends of a ConfigSpec (filter criteria) (for example lot 1, or serial number 1-1000)

In Workspace, you've got 2 columns indicator : one is the "aboslut latest", the other is depending of the config spec you use ...

if you don't want this behaviour, you have to set some transitions and accesrules for example, to deny Revise for a non Released (ie lifecycle state) part, and deny checkout of a Released part.

regards

Gregory

[MikeLockwood]

Hard to believe that this can happen. The Revision labels are controlled in a file (e.g. statebasedversioning.xml) registered to the database. In turn the Revision label series is specified in the OIR.

I'd be very interested to see screen shots of a careful test done on this.

[ptc-1763396]

Here are some screen shots showing the out of order revisions on a test part we did. Intentionally seeing if the system would allow it. These are sorted by last mod date. Shows going from 0.1 to A.1 to back to 0.2 then B.1 and B.2 and back A.2 and then B.3 on to C's and 1.1+. The other shot shows going from a C.2 promoted to 1.+ then back to C.3. We purposely did this and the sytem is allowing check-ins of modified out of data.

[MikeLockwood]

Wow... Yes, big problem, it appears.

Time to get a new job at at different company.

[GregoryPERASSO]

Yes but normal behaviour for Windchill ... as each branch version can be checked out independantly ....

As I can see, all the revisions are at the Concept lifecycle state. So if the users have modify acces rights at this state, they are able to checkout any of these revisions .

Access Rights are applied at Revsion level, through lifecycle, not at the "master" level for all revisions

The iteration history table sorted by date only show the correct order of checkout/checkin actions on the different revisions

Users have to update the workspace when object are out of date. It only says that objects are out of date regarding the ConfigSpec. Not that they are not able to modify it ...

I don't think there's an OOTB config to contstrain this behaviour

The way to forbid to checkout a non LATEST Revision is to implement a customization (ie listener) which will demote on a Revise action the previous Revision to a lifecycle state without modify acess rights (or move the previous Revision in a folder with no modify access rights)