PDM, Do your Designers/Engineers have permission to delete files in the vault?

[bnemec]

PDM Admins, please chime in.

We started out with the CAD users able to delete files that are in WIP or a couple other states in the work flow. Then after a while I removed that permission because some were causing problems (out of ignorance not spite). Now I get weekly emails from users about how to clean up the trash that they've made. Mostly saving a temp conversion file in vault instead of changing folder or saving remodeled part with serial number instead of the part number.

I don't know which way is less bad, I'm about to switch it back so CAD users can delete files. Of course they cannot destroy the files so I can go but them back. Is there a way for PDM search to show deleted files maybe just to the admin account? All of the data is still there.

[matt]

I used to set it up so that no one but me had actual delete permission, but I would let users move their unwanted data to a special folder which I would check and clear out from time to time. Don't let users really delete stuff, that can just cause heartache. Restoring a db from backup just to get a file someone deleted accidentally is a royal pain.

[bnemec]

I used to set it up so that no one but me had actual delete permission, but I would let users move their unwanted data to a special folder which I would check and clear out from time to time. Don't let users really delete stuff, that can just cause heartache. Restoring a db from backup just to get a file someone deleted accidentally is a royal pain.

That's interesting. Move permission was removed before delete; a few users would move the whole tree because they weren't paying attention (or change saturations) combined with there's no way to have MoveTree dialog start with only the selected file checked for action, instead it checks every file in the contains tree. That made one hell of a mess.

I think some of this is learning the granularity of permission settings. The delete permission is in several places; it helps me to think of them as permission "masks" YMMV. Since popular topics have trashed Google's search for that term here's a link https://en.wikipedia.org/wiki/Mask_(computing) Anyway, there's a permission in the Folders tab for the group, enable that.

Then each state in the workflows have the delete permission flag. I >think< if it's not checked for any of the states then only files that have been added to vault be never checked in can be deleted.

This is actually a safe place for what we need. It helps with those files that some trouble users save that are duplicate file names. If no delete permission at all, they cannot delete and cannot check in. Also helps for accidental saves that they knew enough to not check in for the first time.

Thoughts?

[matt]

That's interesting. Move permission was removed before delete; a few users would move the whole tree because they weren't paying attention (or change saturations) combined with there's no way to have MoveTree dialog start with only the selected file checked for action, instead it checks every file in the contains tree. That made one hell of a mess.

I think some of this is learning the granularity of permission settings. The delete permission is in several places; it helps me to think of them as permission "masks" YMMV. Since popular topics have trashed Google's search for that term here's a link https://en.wikipedia.org/wiki/Mask_(computing) Anyway, there's a permission in the Folders tab for the group, enable that.

image.png

Then each state in the workflows have the delete permission flag. I >think< if it's not checked for any of the states then only files that have been added to vault be never checked in can be deleted.

image.png

This is actually a safe place for what we need. It helps with those files that some trouble users save that are duplicate file names. If no delete permission at all, they cannot delete and cannot check in. Also helps for accidental saves that they knew enough to not check in for the first time.

Thoughts?

I used to be able to allow users to move from their own special folder to some other folders, but that was it for move. Of course I'm talking about a different product altogether. I was using ProductCenter. It was pretty good, but not the most popular choice. I'm guessing it was better than Conisio.

There might be a thing called "roles" kind of like what you are calling masks. It's a group you can assign users to so that they get a pre-determined set of permissions. You might have groups called Admin, User, QA, Doc Control, etc...

A lack of real training is seriously holding the OP back. You must see this.

[bnemec]

I used to be able to allow users to move from their own special folder to some other folders, but that was it for move. Of course I'm talking about a different product altogether. I was using ProductCenter. It was pretty good, but not the most popular choice. I'm guessing it was better than Conisio.

There might be a thing called "roles" kind of like what you are calling masks. It's a group you can assign users to so that they get a pre-determined set of permissions. You might have groups called Admin, User, QA, Doc Control, etc...

A lack of real training is seriously holding the OP back. You must see this.

I forgot about the folder move permissions, you bring up a good point there. The user must have move permission in both the source and destination folders, AND the workflow state. I could use that too.

no, what you call "roles" SW PDM calls "Groups" what I mean by masking is there are multiple places for a specific action to be granted or revoked (depends on the verbiage of the check box) For the move file example. The user would need to have "Move File" permission checked in both the source and destination folders and in the workflow state, and seems like somewhere else but I cannot recall right now. The bitwise AND of all of those settings is only true if all of them are set. "masking" may not be proper term for it...
Oh I remember the other thing that can make permissions hinkey, each state has a checkbox that indicates if the permissions would be ignored for any state the file has been through in it's life. So if the box is not checked and the user has permission in that state to move a file, but the file had been through some other state where the user did NOT have permission to move the file then they will not be able to move the file because the permissions in previous states are not ignored.

As for training. You're half right. Most users don't have these problems, too many do. They've been trained on all of these things but the generic PDM training is only a small portion of the new concepts they must deal with when we started PDM and Solidworks.
Define "Real Training" for me?

[jcapriotti]

We do it both ways depending on location. The core project folders are the wild west, we let users freely move and delete files. They only have one generic state called "Initiated" they're in, although they can transition the files to another workflow once the design is further along with the early concept and needs to be revision controlled. Of course, deleted files aren't really being deleted, they are put in the recycle bin and can be recovered by the users.

Once files are moved to the main workflow, they lose the ability to delete and move. Also, for the folders for the final released design files, users lose delete and move access, as well as ECO files. They can transition files in these locations to a delete request state that emails me so I can follow up and delete based on where-used and some other checks. Again, these are just deleted, I rarely Destroy anything unless I'm certain its not needed, usually stuff like imported model junk files. Some of these go to a Cancelled state instead if I feel they should be left visible to some users.

[MJuric]

I didn't vote because around here the answer is "In some places".

Designers can change names, delete etc etc any place where the product is not released. So while we are working on a project all those files are in "Projects" folder. When the project is designed, detailed, checked etc we "Release" the files and move them to the released directory. At that point the only person(s) that can delete files are admin level people. If you want a file deleted in those directories you are supposed to rename it with (DELETE) at the beginning of the file name and the admins are supposed to go around, find those files and determine if they should be deleted or not....or just delete them, which is what usually happens.

[matt]

I forgot about the folder move permissions, you bring up a good point there. The user must have move permission in both the source and destination folders, AND the workflow state. I could use that too.

no, what you call "roles" SW PDM calls "Groups"

phpbb has both groups and roles. Within each group are several roles, and they explain the roles as masks you can apply. Permissions always go to the least permissive setting when there are multiple sources of permissions (user permissions, group permissions, folder permissions for example).

Define "Real Training" for me?

There has got to be admin training. Surely there are consultants for Conisio? I used to do installation, admin training, and best practice docs for PDMWorks, which was supposedly much simpler. When I bought ProductCenter I went to a week of training along with an IT guy, and they trained us on everything from simple db stuff to installation, and all the options as well as CAD integration.

[VicFrauenfeld]

We (Admins) let users delete a file. However, only Admins are allowed to destroy files that have been deleted. If a user deletes a file, they can tell me to restore it right away. I go through the deleted file list about once a year and destroy files that have been deleted more than 2 years prior (if they haven't needed the file in two years, they probably won't need it).

I downloaded a few PDM reports for deleted files a while ago. One will allow me to search for a file that has been deleted by name. The other will show all deleted files in the vault

[AlexB]

Our users have the ability to delete within their own user folder. They can move files out of their user folder to a project folder as they see fit. Any file outside of that, such as a project folder, cannot be deleted. Once a file has moved into any state other than initial, it can no longer be deleted by a non-admin regardless of location.

This cuts down on most issues that I see regarding the emails like "Hey, can you delete this?". Now they're just the occasional "Hey, I moved this to the wrong spot, can you move it?"

[bnemec]

Our users have the ability to delete within their own user folder. They can move files out of their user folder to a project folder as they see fit. Any file outside of that, such as a project folder, cannot be deleted. Once a file has moved into any state other than initial, it can no longer be deleted by a non-admin regardless of location.

This cuts down on most issues that I see regarding the emails like "Hey, can you delete this?". Now they're just the occasional "Hey, I moved this to the wrong spot, can you move it?"

That's interesting. How are the files named when saved into the user's folder? Such as serial number from pdm or part number, whatever the user thinks is good?

Thanks

[bnemec]

There has got to be admin training. Surely there are consultants for Conisio? I used to do installation, admin training, and best practice docs for PDMWorks, which was supposedly much simpler. When I bought ProductCenter I went to a week of training along with an IT guy, and they trained us on everything from simple db stuff to installation, and all the options as well as CAD integration.

I misunderstood, I thought your earlier comment about lack of real training was referring to user training. You meant Admin training. That could be the problem, but the Admin went to the three day PDM Admin course by the VAR shortly before PDM was implemented and has continued to pick up a lot of information along the way. Perhaps the PDM Admin here lacks the intellectual capacity to perform as needed.

[jcapriotti]

The VAR training for PDM admin gives you the basics of what each node in the tree does but there are a million and one ways to configure the system and no amount of training will cover a fraction of best practices. You just have to get in there and get your hands dirty, or hire a consultant.....
Or cry on the shoulders of your fellow PDM Admins.

[AlexB]

That's interesting. How are the files named when saved into the user's folder? Such as serial number from pdm or part number, whatever the user thinks is good?

Thanks

It’s a free for all within a user’s folder, however when a file is included in a project to be released, it’s named the same as the part number.

[bnemec]

It’s a free for all within a user’s folder, however when a file is included in a project to be released, it’s named the same as the part number.

That's interesting, we were told that renaming is a thing of the past once PDM is used. That renaming files for the sake of file life cycle was the old way and not needed in PDM. I'm starting to see that there's still plenty good reasons for renaming files as part of the process even within PDM.
Or am I misunderstanding you?

[MJuric]

That's interesting, we were told that renaming is a thing of the past once PDM is used. That renaming files for the sake of file life cycle was the old way and not needed in PDM. I'm starting to see that there's still plenty good reasons for renaming files as part of the process even within PDM.
Or am I misunderstanding you?

I think there is a whole lot that "Doesn't need to be done" because computers "Don't need that". However that doesn't matter when humans have to use the same data that the computers do.

I "Rename" things on every project I do. When I'm designing something all my manufactured part numbers are something like YYYYYY-YYXX. Same format as our [project number][part number] but I don't actually assign a part number to it just "XX". I do that because when you're designing something you might end up with a whole lot of parts you started with that you don't end up with.

For purchased parts I do the same thing except I throw in the manufacturer and it's part number.

When I get to the point of "Ok, that will work" I then go into our ERP and pull numbers for all the purchased parts and then rename all the files to the correct format. This leaves me with a nice clean BOM where all the part numbers and purchased part numbers end up being sequential.

The project is then checked and released and moved to the release folder where I no longer have delete rights....well I do because I have an admin log on...but most other people can't.

[JSculley]

That's interesting, we were told that renaming is a thing of the past once PDM is used. That renaming files for the sake of file life cycle was the old way and not needed in PDM. I'm starting to see that there's still plenty good reasons for renaming files as part of the process even within PDM.
Or am I misunderstanding you?

Renaming is fundamental to our use of PDM. Models get plain simple names (BRACKET, SHAFT, HOUSING, etc) when designing, and when released they are renamed with a part number acquired from the MRP system. I can tell if a file represents a 'real' released part simply by looking at the file name.

If anything, PDM makes renaming more useful, since all the files that reference a renamed file get updated with the new name automagically.

[AlexB]

That's interesting, we were told that renaming is a thing of the past once PDM is used. That renaming files for the sake of file life cycle was the old way and not needed in PDM. I'm starting to see that there's still plenty good reasons for renaming files as part of the process even within PDM.
Or am I misunderstanding you?

We typically re-name them only once we pull a part number to make the file official. Prior to being re-named, it can be called whatever the engineer saw fit at the time. This will then no longer change for the life cycle of the files.

Renaming is helpful in the sense that we want our drawing and part to have the same name so that the "open drawing" in the right-click menu works. Aside from that, naming convention doesn't really do much since we use the data card and other variables to search and navigate the vault.

[jcapriotti]

Renaming is fundamental to our use of PDM. Models get plain simple names (BRACKET, SHAFT, HOUSING, etc) when designing, and when released they are renamed with a part number acquired from the MRP system. I can tell if a file represents a 'real' released part simply by looking at the file name.

If anything, PDM makes renaming more useful, since all the files that reference a renamed file get updated with the new name automagically.

Until they try to name it "Bracket" and get that it's already used. "Bracket1", already used.....and so on. For our "Wild west" area of our project folders we instruction the users to prefix files with their project number. "PRJ0125-Bracket.sldprt", still not fool proof but helps when searching and mostly avoid the unique filename trigger.

[JSculley]

Until they try to name it "Bracket" and get that it's already used. "Bracket1", already used.....and so on. "

We allow duplicate file names in the vault. The pre-release files are already segregated into projects, so there is rarely any name collision, especially since in a project the creation of subfolders is highly discouraged.

[bnemec]

We allow duplicate file names in the vault. The pre-release files are already segregated into projects, so there is rarely any name collision, especially since in a project the creation of subfolders is highly discouraged.

How do you get schizoworks to use the correct, same named file? Oh wait, because you use project folders and it looks for that file name in the same folder hierarchy as the assembly first?
Edit, not even hierarchy, I just re-read your post and understand the point of "creation of subfolders is highly discouraged." So that's how SW and PDM are meant to be used, all projects-based directory structure. We don't have project folders in our production data set.

[JSculley]

How do you get schizoworks to use the correct, same named file? Oh wait, because you use project folders and it looks for that file name in the same folder hierarchy as the assembly first?
Edit, not even hierarchy, I just re-read your post and understand the point of "creation of subfolders is highly discouraged." So that's how SW and PDM are meant to be used, all projects-based directory structure. We don't have project folders in our production data set.

The project folders are only used during the design phase. When parts are released for production, the part, assembly and drawing files are renamed and moved (via a custom add-in, but could be done manually as well) to a more organized folder structure based on part number. Ideally, when the project is complete, the project folder has no SW files in it. This never happens of course because ideas are tried and abandoned, parts are downloaded but not used, etc...

[bnemec]

The project folders are only used during the design phase. When parts are released for production, the part, assembly and drawing files are renamed and moved (via a custom add-in, but could be done manually as well) to a more organized folder structure based on part number. Ideally, when the project is complete, the project folder has no SW files in it. This never happens of course because ideas are tried and abandoned, parts are downloaded but not used, etc...

I see. I thought "no duplicate file names" setting is per file extension and vault wide, how do you prevent duplicate names outside of the project/development folders?

[JSculley]

I see. I thought "no duplicate file names" setting is per file extension and vault wide, how do you prevent duplicate names outside of the project/development folders?

Automation. Users know (through training) to work only in the project folders (the creation of project folder structure is automated through a PDM template) and the release process does all the renaming and moving. The easiest way to prevent users making mistakes is to automate as much of the process as you can. They appreciate that you are removing a bunch of manual steps for them, and there's less work from an admin point because stuff just ends up where it is supposed to.

[jcapriotti]

@JSculley Maybe your projects are easily separable. This would blow up in our faces and one project could reference another. Duplicate file names have bit us hard in the past.

In some newer areas of our vault for some document types, I've taken to just having serial numbers generated which can be renumbered later with our default part number schema if it makes it out of the conceptual stage. I just got tired of trying to fix unique filename issues. Herding 100+ engineers and designers ain't easy.

[KennyG]

I'm guessing most folks on here are talking about PDM in regard to PDM Works or Enterprise and not generic multi-brand "PDM", but I am...

In my experience in typical enterprise PLM systems with PDM capability, once a file is in the vault it is tied to PLM objects (Design) that are related to other objects (Item) and it is a mess to try and back out that data. To really delete it, relationships must be removed, and all associated objects deleted, not just the file in the vault. Thus, not easy for a user to do. We do not provide that permission to the end user, but rather leave it up to the Admins who understand the process.

[jcapriotti]

I'm guessing most folks on here are talking about PDM in regard to PDM Works or Enterprise and not generic multi-brand "PDM", but I am...

In my experience in typical enterprise PLM systems with PDM capability, once a file is in the vault it is tied to PLM objects (Design) that are related to other objects (Item) and it is a mess to try and back out that data. To really delete it, relationships must be removed, and all associated objects deleted, not just the file in the vault. Thus, not easy for a user to do. We do not provide that permission to the end user, but rather leave it up to the Admins who understand the process.

I think we were talking PDM Pro (Enterprise) specifically. PDM will let you delete the file and orphan the links. In Windchill, once its linked to something, you cannot delete anything unless you also delete the version of the objects it's linked to. Big headache for us right now as we are migrating data and making a lot of mistakes and sometimes can't undo it.

[KennyG]

I think we were talking PDM Pro (Enterprise) specifically. PDM will let you delete the file and orphan the links. In Windchill, once its linked to something, you cannot delete anything unless you also delete the version of the objects it's linked to. Big headache for us right now as we are migrating data and making a lot of mistakes and sometimes can't undo it.

Feel for you Jason. Data migration is the worse. We ran portions on a DEV instance and QA'd each portion until we got what we thought was right then we reset the server back to "new" and repeated till we got through with no errors. Literally took months...

[jcapriotti]

Feel for you Jason. Data migration is the worse. We ran portions on a DEV instance and QA'd each portion until we got what we thought was right then we reset the server back to "new" and repeated till we got through with no errors. Literally took months...

Doesn't help that we aren't just implemented Windchill but also an entire new end to end process thru several new and old systems. And we are trying to 'align' globally with new standards and processes at the same time. Major moving targets that make it difficult to get it right. It's 1 step forward and 2 steps back constantly now for 3 years. I'd be lying if it was extremely stressful at times as I also have to keep the current production systems running. And now we are maintaining two sets of the same data as well (PDM and WC).