Lock Feature

[tcasola]

Intralink used to have lock feature. Since Windchill does not have this feature, users are using check-out to "Lock" assembly/parts. Some items are checked-out for months/YEARS, in order to prevent editing.  There should be a better way to "lock" a part/assembly besides check-out?

A “lock” feature should be implemented in a future Windchill upgrade/version. Since PTC’s best practice is not to have things “checked-out” too long, this feature would be beneficial. As stated, I have some user who have items check out for over a year because there is no “lock” feature. As you know, having items checked out over a prolong time can be problematic, especially if there is a corruption.

[BenLoosli]

I don't understand why anyone would need to lock/check-out a file for over a year?

What purpose does locking the file do, except prevent others from modifying it?

There are other ways to handle those situations without keeping a file checked-out.

Please explain your work flow to help us understand the need to have long-term file check outs.

[BillRyan]

Here are some possible workarounds and alternatives:

1) Use Subsciptions - Have the user subscribe to the object...they will get an email when anybody checks out, moves or even copies the object.  In our collaborative environment user's want to naturally protect their files.  Checkout is good for this...but subscribing is an option.

2) set up a query report to find all objects in the system that are checked out.  We have partially checked out family tables that cause downstream issues.  Inexperienced users will select "Checkout" instead of "Continue" in the Creo Parametric session on family tables that get marked as modifed in session.

3) Set up a folder structure to enable permission control on the folder...the users in that program can only write to the files.

[kpritchard]

Sounds like a symptom of never "Releasing".  My recommendation (and to my knowledge, best practice) would be to use life cycle States in conjunction with your access permissions to prevent unauthorized edits.  In order to edit an Object for which latest version is "Released" the object would need to be Revised in order to generate next version at editable State.  Use Promotion Request or Change Notice to get things "Released" by workflow or Set State manually if you have to

[BillRyan]

The lock feature for us was used by engineers in a Development / Collaborative environment after they were burned by having a user from a different divison or even continent mess up their work.  Checkout is still used for this scenario in Windchill. Sadly, it is a "trust" issue, but nonetheless real. 

Also, we have a nested family table in which a tech support case was open for 6 months with PTC to make it stable.  I've had it checked out for 3 years!  A new engineer wanted to modify it  just last week...the admin from the other divisoin helped him create a stand alone part.

[tcasola]

Dear Ben Loosli,

Thank you for respond. Sorry for the delay in responding back, but I asked a few people why this practice is done. This was their reasoning:

The main reason for keeping items checked out on items not released (Product Released, R&D Released) is to lock the items. Users go to great lengths to make sure the drawings are totally parametric and up to standards.

They like to make sure if a designer changes the model, they are made aware of it so they can update the drawing

accordingly.

As for the drawings themselves, some users prefer updating them themselves.

The length of time depends on the time they actually start the drawing until the point their state is promoted to Release.

I mentioned the subscribe option, but to be honest, no one (nor I) are aware of this feature.

That sounds like something that might be viable for long term. Where can I find more information concerning this.

But to the point, folks use check out to prevent others from modifying a file without knowledge.

[tcasola]

Dear Bill Ryan,

Thank you for taking time out; responding and give options.

I will need to look into the “subscription” option, and pass it along to the workforce.

[tcasola]

Dear Keir Pritchard

Thank you for taking time out and replying.

We “Release” quite often. However, prior to the “Release” state, it appears users will “lock” a part/assembly to prevent it from being modified. In our environment, CCB approval can take day to weeks to months to (yes even) years.

On the drawings, they will denote “see Bob Smith” for location of cad file. When approval is granted, the approver will then contact “Bob Smith” to “check-in” the item, and it will be (re)released.

So it seems users rather “lock” an item to ensure it isn’t “touched"

[BenLoosli]

Are you using Windchill to release and control file content?

Using Lifecycle states can control the state of a part and lock files from change unless a Revise is done.

Using folders in Windchill with ACLs can control who has permission to revise a file.

Subscriptions can notify people when a files state is changed.

If you are not doing release control of your parts within Windchill, you have purchased a very expensive file folder that is doing nothing more than what you get out of any operating system for file control.

[tcasola]

Of course we're using Windchill to release and control file content. We also use Lifecycles, and ACLs.

However no Workflow; Lifecycle or ACL will prevent users with the correct permissions from making (unwarranted) changes.

Subscription may be the answer. 

[BenLoosli]

True, anyone with proper permissions in the system MAY make changes but with Windchill those changes will be document as to who made them and when.

If you ONLY use released drawing and models in manufacturing, then with proper ACLs manufacturing can only see released files.

Maybe the solution is a revised workflow with an additional lifecyle state called something like PendingRelease where only the author (and system admins) of a file may access it.

[tcasola]

GREAT IDEA!!

[kpritchard]

I have recently helped a customer implement in intermediate "Under Review" State that Objects enter after being submitted on a Change Notice and prior to being "Released".  Under Review is also a non-editable State by ACL.

The real issue would seem to be with the slow and cumbersome change process.  If a change is worth doing it should get done in an expedient manner, even if not becoming "Effective" for a period of time.

[dnordin]

We had similar requests here for a LOCK capability in the CS.  We have multiple reasons, some of which are:

1. You get pulled away from your current in process work to do other high priority work.
2. The project funding is suspended and the data is not ready to release or otherwise control.
3. The current user leaves the company and you wish to lock the in work data until another user is assigned to the work.
4. It's easier to lock the data from modification than it is to try to undo or delete unintentionally modified data in Windchill.

I started to investigate using a life cycle state called "LOCKED" w/ ACLs and a simple Set State to move objects from IN WORK to LOCKED.  All of that is easy enough.  The trickier part was deciding how to set it up to get the objects out of the LOCKED life cycle state.  The best configuration would be to allow the person who put the object in LOCKED to use Set State back to IN WORK. The ACL's can be defined with the sudo role of "Owner", but who's the owner of the EPMDoc?  The originator, the last modifier, or ?????  I can assign a group of high end users that are allowed to Set State back to IN WORK, but now the users have to chase down someone in that group to get their data back to a workable state which isn't ideal.

I personally like the lock idea, and I know others here would like the functionality again as well.

I believe the lock should:

- be allowed/disallowed per life cycle state
  You may wish to allow users to lock files at IN WORK, but not at RELEASED.
- be shareable by the originator/owner of the lock [or an admin] to other users and/or groups
  To allow others to unlock the file if needed
- lock only the latest version; or be configurable for all versions at state or latest at state
  To allow actions like purge to still remove old data
  To lock all versions at a state to prevent revising the non-latest
- be configurable to prevent certain actions against the objects while locked
  Don't allow promoting, revising, others?
- be configurable to require a comment or not
- be a searchable item
  All locks
  Locked by

Other options might be:

- allow an expiration date on the lock
- allow a "group" lock so the lock is shared to the entire group from the start
 

I voted it up.

Regards

[tcasola]

Dear Daniel Nordin,

THANK YOU for your reply, and your views. This is what many users have been saying since we've moved to Windchill.

In our business, we've removed the set-state feature (except for Admins) because many users began to abuse it.

This isn't the only feature than was once in Intralink but is no longer in Windchill. Many feel, if it was in Intralink, and worked, why was it never developed for Windchill. Argument can be made that Windchill 8 and/or 9 were new and being redefined. However now that we're in Windchill 10 and/or 11 - some of these older Intralink features should be included in the new upgrades.

[DonSenchuk]

I'm having a lot of trouble following the need for this.

The combination of life cycle states and ACLs do what is being asked. Yes, additional life cycle states and their corresponding ACLs will need to be defined. That's just normal admin work.

(Never mind Project Link doing this sort of thing as well.)

[MikeLockwood]

As others have stated in various ways, the "lock" concept is in Windchill, but one has to translate to the available tools, which primarily include lifecycle states, the ways states are changed and when, and user permissions (ACL's) by state. In addition, adequate planning, user training and support of various approaches for generating new concepts, evaluating multiple parallel change proposals, etc. can help greatly in avoiding having to lock data.

[cmilligan]

An idea that might help since these items are still in development. Setup a "Pre-Released" lifecycle state and revision schema. If the user wants to "Lock" the object they can promote it to "Pre-Released" where modification is restricted (requiring a revision generally). You can decide how restricted that state will be, but make sure it prevents accidental modifications.

The revision schema allows you to revise it thru prototype development cycles and have version control for sending things to vendors, or internal tracking of changes to the design. When actually released you change the revision schema to the final production one. You could probably make it happen without the revision schema change if desired, but you would have to send the iteration to vendors during development.

I also agree that subscriptions would be a great tool for monitoring this. However you need to be careful that you don't subscribe to more than you really care about. I think watching for a revision to a Pre-Released item would be a good event to monitor. The revision shows the user purposefully intends to modify the object, and the user subscribed to it can then ask why.

[olivierlp]

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.