How do you lock down Item privileges based on the Change Order Status in Agile PLM?
By Shane Goodwin on Sep 15, 2008
Often our customers are looking for additional means to restrict Read or Modify privileges on an Item based on the status of related Changes. For example, file attachment checkin may need to be allowed for pending revisions of items only as long as the corresponding ECO is in authoring mode ("Pending" status), but not once the ECO gets submitted or routed. Before Agile PLM 126.96.36.199, achieving the desired business result could be complicated. Now, Agile PLM has some very powerful capabilities to write Criteria against an Item that checks the related Change status. The enhanced functionality around variables such as $CURRENTREV and $LATESTREV can help Agile Administrators write criteria that meet business goals to limit Item Read or Modify privileges.First let’s cover some quick background on Criteria and Roles in Agile. To learn more, please review the Agile Administrator guide. I will also be using concepts about Items, Revisions, Attachments, and Changes with Workflow. To learn more, review the Getting Started or Product Collaboration guides. In my example, I will be relying on the standard Default Change Orders workflow (Pending – Submitted – CCB – Released – Incorporated), though the functionality applies to all types of Changes that constitute a revision of the item (Engineering, Manufacturing and Site Change Orders Classes).
In Agile PLM, Administrators write Criteria to match various conditions. For example, to write a criteria which matches any object within the Items Base Class, simply create a Criteria where the Type is Items and has no additional restrictions. This would match (True) for any Object of a Subclass within the Items Base Class – similar to running an Advanced Search for All Items.
Admins then use those Criteria in Privilege Masks to grant various capabilities to users. For example, create a Privilege Mask for Read using the All Items Criteria. When this Privilege Mask is added to a Role and the Role is added to a User, the User will have access to All Items for Read. Similarly, create a Privilege Mask for Modify using the All Items Criteria and add the Attachment Attributes to the Applied to field. This Privilege Mask will grant a user the ability to Add, Remove, or Modify Attachment rows. Remember that Agile Privileges are additive – the least restrictive privilege for the user wins.
What if you want to grant a user to see (Read) Attachments on an Item Revision when the related Change Order is Released but not Incorporated? With Agile PLM 188.8.131.52+, the Criteria would look like:
$CURRENTREV Equal To Default Change Orders.Released
In the Criteria above, we are checking to see whether the change that created the revision being looked at is equal Released in the Default Change Orders workflow. The $CURRENTREV variable will evaluate the Item Revision at which the user is currently looking. Since each Revision is tied to a Change Order, $CURRENTREV can check the status of the Change Order. If we wanted to match any status of the type released in any workflow, we could have used $STATUSTYPE.RELEASED instead. Note that each revision of the Item could have a Change Order in a different status. This capability opens up many potential use cases to restrict access to Attachments to different depending on the Change status. Engineering users may always need access, while Operations users can only see Attachments to specific revisions.
Now, what if you want to grant a user the ability to modify an Attachment on an Item when it is on a Change Order in Pending, but not after the Change Order is Submitted? It is also easy to create a Criteria which matches no workflow or the Pending status:
$CURRENTREV Equal to $STATUSTYPE.PENDING or $CURRENTREV Equal to $UNASSIGNED
In this Criteria example, we are checking to see if the change which created the revision is in any status of type PENDING or has no Workflow. Once the change moves into Submitted, there will no longer be a match. Using this Criteria in the Modify Privilege Mask from earlier will restrict when Attachments can be added. Admins can also use this type of Criteria to restrict Modify on other Attributes, but the usefulness will vary due to the nature of Agile Attributes.
To summarize, the Items criteria variable $CURRENTREV matches specific or generic Workflow statuses and can also be used to match various cases for the Introductory revision. This matching capability can be used to precisely control modify or read privileges on Items. Another Items criteria variable, $LATESTREV, can check whether the latest revision of the Item is Introductory or Released. If you are testing, make sure to know exactly which Roles and Privileges the user has been assigned (directly or through User Group inheritance). Otherwise, you may not get the expected results.
Hopefully this is a useful introduction to $CURRENTREV and its capabilities to enhance the security of your Agile PLM system.