1 Reply Latest reply on Sep 6, 2017 3:52 PM by Andy Sanders

    Accidental (and almost disastrous) editing of sub assemblies in top level assembly

    Gordon Rigg

      Remember from back in 2013, when we got the "enhancement" from hell that led to lots of important sub assemblies getting trashed accidentally?

      Delete components from subassembly - behavior changed?

      well,  we originally got a registry hack to stop it, then we got a way to restore sensible operation in 2015 - when you select a part in a sub assembly and try to delete it, it asks if you want to delete the part from the sub assembly (that's a change to the sub assembly that is NOT open for editing, and is NOT open in context) or the delete the entire sub assembly (which is any sane persons expectation). A tick in that dialogue fixes that behavior forever (though what you are actually fixing and how to put it right if you get it wrong is less than intuitive).

       

      WELL

      there are still other edits that happen on sub assemblies that you would expect to be impossible.

      If you click on a sub assembly component (remember that sub assembly is not open, and not open in context) you can suppress it. You can un-suppress one from the list on the left. unlike visibility changes which occur in the top level assembly only, leaving the sub assembly file unchanged, these suppression state changes occur in a sub assembly -  that is merely appearing in the next assembly level up - one that you do not expect to be able to edit! (as above with the disastrous deleting of parts).

       

      Never mind, maybe you have WPDM in operation still, and you don't have write access to the sub assembly - so those changes are neatly cut off there so you don't have a disaster.

       

      well, BEWARE!

      I have now reproduced this on two different machines. Without going anywhere near the vault, the pink tick came on on the parts we unintentionally edited. There were no prompts, nothing responded to - we just got ownership of the sub assembly without asking for it.

       

      Now what we work on is installing our sensors on some machine or other. Our sensors are our products, they have many different configurations depending on their operation. I just had to pull a backup of the assembly which is one of our core products because those configs got all completely screwed up from an assembly that had no business editing them, even though ownership in WPDM was not requested (remember I'm on 2016 and WPDM is supposed to be supported until the end of 2017, not "broken" by 2016).

       

      The sub assembly was not open, and was not open in context. It should not be possible for any changes to occur to that sub assembly file. but solidworks is now "enhanced" to allow that unwanted activity. How can i prevent it?

       

      The sub assembly was supposed to be locked in read only mode by WPDM, but without any user input the user was granted write access that was unintended.

       

      Has anyone else found this ridiculous sort of thing happening?

       

      SW "professional" 2016.