Skip to main content
A
Alexander_Bgrd12-Amethyst
12-Amethyst
September 25, 2024
Solved

ACLs for creating downstream branch

  • September 25, 2024
  • 2 replies
  • 1446 views

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?

    Best answer by avillanueva

    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.

    2 replies

    avillanueva
    23-Emerald I
    avillanueva23-Emerald IAnswer
    23-Emerald I
    September 26, 2024

    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.

    J
    jlecoz15-Moonstone
    15-Moonstone
    October 1, 2024

    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.

    A
    Alexander_Bgrd12-AmethystAuthor
    12-Amethyst
    October 1, 2024

    @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.

    J
    jlecoz15-Moonstone
    15-Moonstone
    October 1, 2024

    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.

     

    jlecoz_0-1727798225606.png

     

     

    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

     

    Terms & ConditionsAccessibility statement