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

Extend the "Automatically lock objects added to workspace" preference to the File > Open action

Extend the "Automatically lock objects added to workspace" preference to the File > Open action

According to the current state of the art, the “Automatically lock objects added to workspace” Windchill preference is fulfilled only after a “Add to workspace” or “Open in Creo” action within Windchill, whereas it is not after the “File > Open” action started in Creo (that causes an implicit addition to the workspace of the objects opened).

This behavior not only seems heavily disadvantageous for Creo users not used to Windchill (the opening of a CAD Document from File > Open in Creo Parametric native User Interface is for them considerably more natural than open it from Windchill) but it also lacks in coherency since Windchill permits both the way to operate (one should consider that for other options, e.g. Rename, the action has been disabled in Creo when there is an active Windchill connection).

5 Comments
Regular Member

I heavily support this idea for the same reason Luca mentioned.

If you think about adding components from e.g. a library to an assembly most users retrieving their files using the standard "File open" way, browsing to the object to be assembled instead of searching it first / using the "Add to workspace" function

Aquamarine

I agree the lock functionality should apply when Creo calls for objects from Windchill on the fly.

However, I'm a firm believer that locking objects would not be needed if family tables behaved as well as stand-alone objects in a windchill environment.  In our company, the lock function was put in place as a "band-aid" to prevent the "marked as modified, but untouched" issue with family tables.  There were a few new issues that popped up due to locking that has resulted in most user's going away from the practice.  One example, was a partially locked family table in a non-active workspace prevented objects from being downloaded into an active workspace.  And we don't even have instance accelerators!     

Regular Member

I voted this up in a hope that a larger discussion would start on locking objects.  Locking, checking out, and controls around these ideas were different in Intralink 3.1.  This was a good thing for CAD Documents.  I would suggest that there are other concepts like automatic workspace locks on non-checked out objects or objects the user does not even have modify permission for.  This way we will stop having users modify locally standard library objects they will not be able to return to the commonspace.

Community Manager
Status changed to: Acknowledged
 
Amethyst

I might be going crazy here, but this looks like this has been implemented in Creo 5.0.2.0 (I have not tested this in earlier builds). Can PTC confirm this?

 

i.e. when "Automatically lock objects added to workspace" is set to Yes, Creo 5.0.2.0 seems to be acknowledging this setting and actually locking all models pulled in via a File Open command (from Creo itself, not the browser). I cross tested this with the setting off, and with Creo 3.0 M160, and those did not auto-lock all objects that were opened.