PDM, Is there a user/group state permission to list file but not allow caching it?

[bnemec]

This probably sounds like a bad thing to try to do, but I believe it would be nice if we could set permissions for some users (not design eng, but sales or purchasing for example) so that they can see that the file exists in pdm, but cannot access it.

Reason: It's straightforward for CAD users to understand why we have both SE and SW files for one part number. For non-CAD users it's just confusion. To make matters worse they don't understand that the SE files are the controlling document ONLY if there is no SW document. Needless to say I'm concerned that they stop looking at the first file they find and assume it's good to pull information from that. I get the, "If it's not right then how come I can see it?" response It doesn't help that windows defaults to hide file extensions and most don't memorize the icons so, again thinking non-CAD users, they don't know SE from SW. I urge them to make sure the revision in PDM matches what's connected in the ERP system (source of truth). Tangent; the drawings are all connected to ERP system so these non-CAD users are primarily trying to view the models, so no title block rev to make obvious what they are looking at. Anyway, we have a state for the SE files that are no longer maintained and have been superseded by SW files. So I can use permissions by user group for files in that state. But the permission named "Read file contents" is poorly named IMO, the file doesn't even show up in vault view or search tool if this is unchecked. This is not what we want. What we want the let the user find the file but not use it, only way that I know is to prevent caching the file so there's no local copy to open/view.

[jcapriotti]

We kind of handled this by only allowing those types of groups to view the "PDFs" of finished drawings. If we were staying with PDM, I'd probably start publishing 3d viewables in additional to our 2d PDF viewables.(eDrawings or maybe some other 3d format). Since we create a 2d pdf viewable that is a separate file for each revision, I can more easily control what states and revisions users can see.

[bnemec]

We kind of handled this by only allowing those types of groups to view the "PDFs" of finished drawings. If we were staying with PDM, I'd probably start publishing 3d viewables in additional to our 2d PDF viewables.(eDrawings or maybe some other 3d format). Since we create a 2d pdf viewable that is a separate file for each revision, I can more easily control what states and revisions users can see.

We've been considering that route too. Mostly me advocating it, as you state, for better control as the publishing of 3D viewable file to a secured network share could be a task that is run when files are transitioned to Released state. But, someone advertised how nice PDM does controlling access to all the other people in the company; but the longer we use it the more I see that only CAD users should be using PDM and view only clients just aren't that good of a plan.

But, PDM does have a pretty good search so it helps the other people find data they need. Putting them in network share reduces the searchability from what PDM offers.

[jcapriotti]

Windchill works on this principal for downstream users. Cad documents are published to PDF for drawings and the Creoview format for 3d models. They are then attached to the objects representing "Parts item masters". So most non CAD users only see that content, they can't open the SolidWorks files as they would need a separate expensive license.....and you get into all kind of UI complexities. Even for basic users, the base Windchill license costs a lot so we are pushing the PDFs to another less expensive repository software so users further downstream in our factory and field ops can view.

[bnemec]

@SPerman I have to ask, is there a reason you liked my question other than accidentally clicked on it? A use case maybe?

[SPerman]

It is an interesting problem. We are no where big enough to have that problem, but someday there will be more than just me using PDM, and it is clear to me that PDM is a great solution for SW files, but not so much for everything else. It is also fairly clear that the two options I am aware of that would handle other documents (windchill and teamcenter) both cost way too much to consider anytime soon.

[AlexB]

I don't remember what exactly I was doing when I discovered that it's possible to have certain states that users can see and others that they cannot by toggling the "Read File Contents" permission.

If at least one state gives them permission to "Read File Contents" then they can see the file in the system, but when they look at the version history, all the versions that they don't have permission for will be greyed out. I honestly don't know if this helps your use case at all but it was an interesting discovery that could potentially be used to control viewing permission in a similar manner.

[bnemec]

It is an interesting problem. We are no where big enough to have that problem, but someday there will be more than just me using PDM, and it is clear to me that PDM is a great solution for SW files, but not so much for everything else. It is also fairly clear that the two options I am aware of that would handle other documents (windchill and teamcenter) both cost way too much to consider anytime soon.

Thanks. As much as I complain about SW PDM all things considered it's quite a good solution; in it's place. I cannot imagine trying to manage CAD files in some cloud mydrive, dropbox, thing. On the other extreme, as you mentioned, is the likes of windchill and teamcenter with the big cost and from what I've heard, substantial management overhead. I think the only places we really struggle with SW PDM is when what we need is precisely what it wasn't intended to do. In a way, we were sold a product that doesn't fit our needs very well. But, it might be the least bad fit available.

[JSculley]

Anyway, we have a state for the SE files that are no longer maintained and have been superseded by SW files. So I can use permissions by user group for files in that state. But the permission named "Read file contents" is poorly named IMO, the file doesn't even show up in vault view or search tool if this is unchecked. This is not what we want. What we want the let the user find the file but not use it, only way that I know is to prevent caching the file so there's no local copy to open/view.

Why would these users need to be able to find or see a file that has been superseded and should not be used? Out of sight out of mind would be a good thing, no?

One option is to alter the SE files so that it is blatantly obvious to anyone opening it that it is not to be used. Before implementing PDM, we had some duplication of hardware items where the file names were different. For example, we have 2 configured flat head cap screw models, one for coarse threads (UNC FHCS.SLDPRT) and another for fine threads (UNF FHCS.SLDPRT). At some point someone made a third model with coarse thread dimensions and just called it FHCS.SLDPRT. It snuck its way into a bunch of assembly models. I'm not wasting my time correcting all those assemblies. I just add a feature to the rogue model so that it is obviously the wrong item and points the user to the correct item:

When people open this part, or assemblies with this part, they immediately see the issue.

[bnemec]

Why would these users need to be able to find or see a file that has been superseded and should not be used? Out of sight out of mind would be a good thing, no?

One option is to alter the SE files so that it is blatantly obvious to anyone opening it that it is not to be used. Before implementing PDM, we had some duplication of hardware items where the file names were different. For example, we have 2 configured flat head cap screw models, one for coarse threads (UNC FHCS.SLDPRT) and another for fine threads (UNF FHCS.SLDPRT). At some point someone made a third model with coarse thread dimensions and just called it FHCS.SLDPRT. It snuck its way into a bunch of assembly models. I'm not wasting my time correcting all those assemblies. I just add a feature to the rogue model so that it is obviously the wrong item and points the user to the correct item:

image.png

When people open this part, or assemblies with this part, they immediately see the issue.

Out of sight not so good, out of touch good. They will go looking wherever they can. It seems people will look for something until they find it, even go looking in places they've been told are no longer valid. I would like to catch them before the leave the vault and go out to the network shares. So out of sight likely means they find other wrong stuff that is even harder to control. If they find it but cannot access it, then they will likely report that somethings broken giving me the chance to catch the train before it leaves the rails.

I like the anecdote about adding strange feature to wrong model to make it obviously wrong. Before PDM we would just move the file, intentionally breaking the file ref; forcing the user to update. This was usually only done with old revision that should have already had all it's where used updated per normal process.

However, for this case there's thousands of SE files to make obviously wrong.

[JSculley]

Out of sight not so good, out of touch good. They will go looking wherever they can. It seems people will look for something until they find it, even go looking in places they've been told are no longer valid. I would like to catch them before the leave the vault and go out to the network shares.

How about using virtual documents?

Move the SE files where they are inaccessible and then put a virtual document in their place. They show up in search, they use the same data card (you have to make sure the data is copied somehow), but if you try to open them, you just get the PDM File Viewer dialog.