Prevent revision on some folder

I would like to brainstorm here an idea I had today and I briefly tested and it seems to work.

Our current vault is a broken implementation of PDM, according to some misconceptions the former admin had. That admin was not a technical person so the approach was quite “creative”. Bear with me please.

We have different technical department, each with its “normal customized data” and some “standardized data” they tend to reuse for our machinery.

We have a standard user group that does everything including approval and state change for revisions. User ask for approval to his supervisor and fills the date and signature on the datacard.

for revisions the user can trigger them, later if he sees compatibility issues or the supervisor point them out, he aborts the revision, tree copy the data to a new part number and asks me to roll back the aborted revision to its previous approved state.

This kind of logic works decently, but there are standard data that only trusted users should revise or even triggering a revision is not a good thing.

For those data our former admin just deleted the checkout, move and delete authorizations from those “standard folders” in theain user group.

it sort of works, in a sense, but the users are still able to trigger the revision state and due to the lack of checkout we have some failure message during ghe transition as the file cannot be wrote and one dispatch also fails for the same reason. the user cannot edit the file, but we need to rollback it to its original approved state.

My idea is to use two parallel transitions with the same name that goes from approved to under revision: one is for standard parts revision aurhorized user group and pdm admins, while I move the nornal users in the other transition with a condition on the path.
The condition is that the path must not comprise the characters "standard" which is our folder convention for those parts.
usually my depts have “001. standard”, “001_standard” or something like that in japanese since they insist to use two bytes characters inside the vault (which is a very bad habit)

All good unless your users call the folder “I do not like our standard” … :joy:

1 Like

Is that a real folder " I do not like out standard" ?

no, it is nor real, but we have some file called 〇〇_standardization, so if i just put standard% into the file path check which includes filename I will catch them too even if provisional or temporary data outside the designated standard folders which names end in "standard" hence the “\” at the end.

But do not worry, someone will just block the transition somehow…

You could have two different workflows, with standard files in one and custom files in the other. You could do it in one workflow with parallel transitions as well. I would two workflows if there are a lot of differences.

Either way you need the files in two different folder structures to filter the files into the correct workflow (if separate workflows) or create a condition (if parallel transitions) to send them down the right route.

1 Like

For us the workflow is the same for all files and it is only their location to determine if the supervised revision is needed or not (i.e. moved to a standardized unit subfolder later after creation somewhere else)

I am just trying to put some order in our mountain of data with broken workflows and half backed practices. it is like walking on LEGO…

Parallel transition conditions will work for location, Just need to make sure the files are in the correct folders and limit who can move them.

Only catch with sharing the workflowstate is if you need users in two groups to have the ability to edit only for their relevant group. But you should be able to set the folder location permissions to accomplish that for each group.

1 Like

Thank you for the comment. This is what the former admin was trying to do with folder permissions and we have it already in place.

・”Engineer group” is excluded from the standard folders for add move, rename and checkout
・”Standard supervisors group” is added to some engineer group selected members and standard folders content is allowed to be moved,deleted etc. for them

From a folder perspective it is ok even right now, but as I explained above the transitions are not affected by the folder permission and they are, objectively, broken right now in their current state of affairs. Parallel transitions, as you mentioned, must be divided by their user groups and the conditions applied, but it is not a problem for us.

1 Like