cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X

Add preference to prevent modifications to an earlier version from being snapped to the latest when doing an update

Add preference to prevent modifications to an earlier version from being snapped to the latest when doing an update

Status: Archived Submitted by 3-Visitor on ‎May 25, 2017 07:17 PM
5 Comments (5 New)

In Windchill 11, if you select to reuse local content when doing an update, the modifications to an earlier version will be snapped to the latest version.  This could allow someone to easily inadvertently overwrite changes made in the latest version.  This was not the case in Windchill 10.2.  I would like a preference that controls whether the changes are snapped to the latest version or the users receives a conflict.

The current Windchill 11 functionality:

- User has old version in their workspace and makes a modification (maybe they just save layer changes)

- File in workspace is now shown as out of date and modified:

update1.PNG

- User selects file to update and uses the reuse icon:

update2.PNG

Version number in the workspace is updated to the latest but the content file is NOT replaced so user can now check in.  This makes using the reuse icon very dangerous so we have told users not to use it.  But with it defaulting to download, it is easy for the user to overwrite files they have changed.  So there is no good option...

I would like a preference that would go back to the Windchill 10.2 functionality.  If reuse is selected for an out of date version that is modified, the update gives a conflict and the user must decide to either keep their changes or update to the latest version.

See more ideas labeled with:
5 Comments
swood
6-Contributor
6-Contributor
‎May 26, 2017 08:06 AM
‎May 26, 2017 08:06 AM

I'm just spit-balling because I haven't run into this, but could it be that since you updated your Windchill preferences have changed? I'd check these to make sure they are not affecting it:

  • Reuse Modified Workspace Content
  • Set Configuration for Add to Workspace
cmilligan
3-Visitor
3-Visitor
‎May 26, 2017 10:33 AM
‎May 26, 2017 10:33 AM

Are you intentionally modifying the presumably RELEASED version? If not I would try to lock the objects in the workspace instead. If you changing them on purpose generally the ACLs are set such that you cannot check those in. Can you explain your setup a bit more, and why you are doing what you are?

adawkins-2
3-Visitor
3-Visitor
‎May 26, 2017 12:52 PM
‎May 26, 2017 12:52 PM

Thanks for the suggestion but I checked our preferences already.  After 2.5 months on a call with PTC I was told that this is intended functionality.  If you go to page 35 of https://support.ptc.com/WCMS/files/170670/en/ProEWCInteg.pdf you'll see:Capture.PNG

This is not what our users expect but I assume they changed this behavior because some people want it.  I'd just like a preference so I can control it.  As a workaround we set the update preference to download files.  This means it overwrites users changes by default which is a bit aggressive but hasn't caused problems so far since we did some training along with this change that users need to be careful when updating.

adawkins-2
3-Visitor
3-Visitor
‎May 26, 2017 01:03 PM
‎May 26, 2017 01:03 PM

This is all work on Work in Progress, unreleased files.  It's pretty common for people here to end up with files with changes made just for personal use - you change the layers and do save status, etc.  In Windchill 10.2 we used reuse as the default file action for update actions and had update pull all required dependents.  This meant that if you had made changes to a component and updated the assembly, it would attempt to update the component too but it would fail because the component was changed.   

In Windchill 11, it would save your current workspace file (a modification of an earlier version)  but update the version so you thought you were looking at the latest.  This caused confusion (people wondered why their version didn't have changes other engineers said they had put in the latest) and in a few instances people then made modifications to that version and checked it in causing us to lose work. 

We've since updated our preferences so that update operations default to downloading files.  This means it overwrites users local changes but we did training to alert people to this and haven't had any issues.

olivierlp
Community Manager
Community Manager
‎Jan 05, 2022 09:50 AM
‎Jan 05, 2022 09:50 AM
Status changed to: Archived

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.