Admin Ability to Break EPMBuildHistory Links

[tcurry]

Re: deleting files in WindChill - impossible?

Some history and dialogue can be found in the linked discussion above.

However, to date our PTC contacts still tell us this is impossible in your current product design.  This is unacceptable in our eyes.

Please add a role or feature where a system admin can break EPMBuildHistory links and delete mistakes from the system.   A recommended stipulation is that the links to be broken should be affecting non-latest iteration parents.

If the ability is limited to super admins and there is a consistency check that verifies that the CAD structure being affected is not the latest iteration for the affected assemblies,  then this would be a VERY much welcomed improvement to the Windchill product.

Users make mistakes.  Admins should have access to clean it up when the users report the mistake to them.   Please fix this!

For futher clarity:

• CAD Document Assembly 111 is created with child component CAD Document Part 333.   This assembly should have used the existing CAD Part 222 instead.

• User replaces 333  with the 222 CAD Part and Checks In the assembly again.   Therefore, the latest iteration of the assembly is linked to CAD Part 222.   The non-latest assembly was linked to CAD Part 333.
• Admin deletes the CAD Part 333,  selecting confirmation to break EPMBuild History link.
  
  

• The CAD structure of the non-latest iteration of Assembly 111 no longer shows any evidence of CAD Part 333 in the structure.
  
  
• All is well because the latest iteration of the Assembly 111 shows a CAD structure linked to CAD Part 222.

[klozier]

What about being able to have an object be "marked" as obsolete?  So some implementations have used life cycle states and access limited containers to make an object inaccessible.  I would think that a system wide feature to mark something as "obsolete" or "redacted" would be a great alternative to a delete.  The feature would ideally keep the object from being used, but not violate dependencies/history.

[tcurry]

One option we are considering and have played with is moving the mistake file to a "Trash bin"  Product Container that the users don't have access to.  But this is not ideal and does not actually get rid of the junk.  It just hides it.

[TomU]

The CAD structure of the non-latest iteration of Assembly 111 no longer shows any evidence of CAD Part 333 in the structure.

This is going to cause a problem if you ever try to open the non-latest iteration "as stored" (or view the old version in Creo View).

[tcurry]

Indeed it would, Tom,  except that in all scenarios that we would use this feature,  that iteration was meant to be connected to the original component and not the mistake file that the user created during a poorly executed Save-As.  In other words, CAD Part 333 (In-Work) was a Save-As mistake generated from the CAD Part 222 (Released).

In these sitations, the user has to report the mistake to the administrator and explain that they have replaced the mistake file for the correct one and checked in a new iteration of the assembly(ies).   The file that we want to delete was never meant to be, and is not released.  The admin delete ability could never be used to delete a released part.

The administrator would be the only person to ever have access to perform such a delete, but it would still be much easier than deleting all of the iterations of the assemblies, sub-assemblies, WTParts, etc, that are preventing the delete.  I've recently spent an entire day sometimes trying to track down all of the links and iterations of assemblies linked to a mistake file so that I can pull down copies of them, Save-As for backup,  and then delete all of the assemblies, sub-assemblies, and finally the mistake file.

It's a MAJOR waste of time when a simple admin delete that would allow an expert/administrator the ability to wipe it out and break the links would save us a lot of time and aggravation.

[klozier]

The idea I suggested could consider the configurations like as stored.  If "redacted" then when that object is called there would be something there to refer to.  Think of it as a redirect page.  An admin type uses the "redact" command.  In completing the command there is a wizard that requires some explanation for the redaction.  Then if that object were referenced/called there would be something to return v.s. deletion that leaves a dead end.

[tcurry]

It turns out that PTC does seem to have a tool for this situation that I described in the original post.  The WCTK tool has to be installed in the Windchill environment by the system administrators.  We are installing in our test systems now for verification that it works as we expect.

One other use case that we have come up with is as follows:

User creates WTPart version A.0.   No CAD model linked, no document linked.

User creates CAD files in workspace and links them to the WTPart  (in workspace).

CAD files are checked into commonspace causing WTPart to check in and become iterated  (committing the link to commonspace).

User realizes that the CAD files were generated from the wrong template or for whatever reason needs to be redone.  User wants to delete the CAD files completely and start over again back at the point when the CTPart was at A.0 without any CAD.

In theory, the latest iteration of the WTPart and latest iteration of the CAD should be able to be deleted.  The caveat is that the latest of the CAD is the only,  and the system will not allow you do delete latest of both items in the same delete window.

User,  orgadmin,  and wcadmin all go through the steps to try and delete the latest iterations of the CAD models and WTPart,  but leave the WTPart revision A.0 in the system.

WTPart A.0 had no links.  There was no issue.

Only A.1 of the WTPart had links,  and we want to delete that iteration.

Using Delete latest iteration doesn't work,  because it complains that we cannot delete the latest iteration of the CAD since that's the only iteration of the CAD.  (Yes! That's the objective, to delete the only iteration there is)

I also cannot delete the latest iteration of only the WTPart because it complains about the EPMBuild history links.  

I content that there would be no harm in deleting the only iteration of the part which had the links!!!!

[lnunes]

One major consideration for me in this case is about the deleted item number availability. In our actual scenario, a number should not be reused ever.

A secondary consideration is about history. We need to be able to open older assembly versions, what would be impossible or generate errors if one item is missing.

Said that, it should be done only if this CAD had never being released or published.

[sdekooninck]

This is an excellent idea that would solve many pain points today in the administration / cleansing of the data. 

[tcurry]

We have installed and tested the WCTK tool.

it works as expected.

in the original scenario above,  

assembly version A.1 is linked to child #333.

Assembly version A.2 is corrected and linked to child #222.

the WCTK tool allows admin to delete specific iterations and thereby remove version A.1 of the assembly and all existence of the mistake component #333.

this avoids any case that someone might want to open Assembly A.1 which would have missing child links inside.

[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.