ACLs for creating downstream branch

[Alexander_Bgrd]

There are two departments (engineering and operations) and engineering departement is responsible for creating the eBOM. The windchill part will be released and given a specific state.
The operations side of the company then needs to create a downstream branch in order to split up the eBOM and make an mBOM.

It looks like that in order to be able to create downbstream branches, the user needs to have 'Modify'-rights on the upstream WT-part, but I don't want everyone who must be able to create downstream branches (operations department) to be allowed to modify the upstream parts (responsibility of the engineering department).

Am I overlooking some settings or is this just default behaviour and should I tell operations to be carefull with upstream 'design' parts?

[avillanueva · Accepted solution]

This article addresses this but answer is nope: https://www.ptc.com/en/support/article/CS214993?source=search

Some work arounds might be to use different states in those downstream views. Other options is customization to hide the checkout action on downstream views if the user is not in a special group.

[jlecoz]

There another solution to investigate if it meets your requirements which is to use a workflow to enable the Modify ACL on an object.

The user who need to do the modification could trigger a workflow that would send an approval request to someone, and if approved he could have a Modify access to the object. When he has done his task the workflow ends and the access is removed.

Instead of a "static" setup done with the Policy Administrator, it adds an additional "Dynamic" access rights level.

[Alexander_Bgrd]

@jlecoz So in theory, I could implement a new workflow named 'Initialize Project MBOM'.

1. When userA initiates that workflow, an approval request (or in other words an 'Are you sure you want to do this') is sent to userA.
2. UserA approves the request and then he will have Modify access on that specific project-WTPart or all WT-Parts?
   • Would this then work by assigning a role with additional ACL's?
3. When userA then finishes the task, the ACL's are removed and he can't modify the part anymore

Do you have an example setup for this?

Thanks in advance.

[jlecoz]

Here is an example:

Go to the variable tab of the activity and update the primaryBusinessObject variable, in your case the PBO should be the WTPart associated to the process.

User assigned has to be member of the team and its role should be mapped into the team template of the primaryBusinessObject

The task should be assigned to a role.

When you trigger the workflow the task is sent to the role and he gets permissions you set. Notice that you can only grant permissions.

That can be demonstrated OOTB by trying to modify a Released Document.

Initiate the workflow, assign it to a Released doc and show how available actions are changing.

Regards