Gaining finer access control through attribute level changes

This blog is created as a response and solution to the above PLM challenge, This is a part of our weekly Wiser Wednesday Challenge on Linkedin – Aimed to add value to the PLM community.
Check out Quiz #4 on our LinkedIn page.

Gaining finer access control through attribute level changes

Generally, such a requirement is not a common expectation from the client side, yet during my journey in the PLM domain. I have encountered such a requirement multiple times. Multiple solutions exist to solve this use case.

Let’s talk about the requirement first and then focus on the possible solution approaches. Here we need to tackle the issue of establishing ‘attribute-level’ access control, not ‘object-level’ access control as per the company requirements. Hence, standard ACL configurations will not help us anymore. Below, I will be visiting all the possible solutions.

Solution approach 1:

We can implement two different forms to store such attributes i.e., one form for Eng. Part & another for the Mfg. part. In order to edit these properties by a specific group, we need ACL which will enable access control to the Engineering group and the Manufacturing group. Based on the user’s group the users will be able to edit the information in these tabs. 

Solution approach 2: 

This problem can be resolved by using XML rendering stylesheets, specifically by registering separate stylesheets for the Manufacturing & Engineering groups and using the option modifiable = false in each of the stylesheets for the attributes where the user shouldn’t have edit access. The users will not be allowed to change the attributes that are irrelevant to them using this method, even though they will be able to edit the parts where modifiable = false is valid. 

Solution approach 3: 

Moving on to the third approach, implementing a pre-condition extension with a single generic property and attaching it to each property that needs to be validated. If the user tries to edit a non-relevant attribute, the pre-condition on check returns an error to the user. The group and attribute combination can be maintained using preference.  

e.g. create new preference prop_group_edit_mappings and mention values like  

Enggineering:prop1,prop2,prop3 

Manufacturing:prop4,prop5,prop6 

Engineering & Manufacturing represents the actual groups in the organization and prop1, prop2 etc. represent the internal name of the actual properties on the object. 

Each property extension will check if the logged-in user’s group is present in the preference and if the name of the property is present against that group name then in such cases it will return ITK_ok else it will return an error saying the user cannot edit the attribute. 

What using one of the approaches implies:

Approach 1: 

1. It adds extra effort to the forms access management and we need to make sure forms also get the required status according to part. 

2. Utilizing the attributes from forms will be tricky in the downstream processes as they are not directly placed on the parts. 

3. Usually, forms are not much preferred to store such attributes. Forms are mostly used for workflow use cases to show the forms during workflow task signoffs. 

Approach 2: 

1. This option highly depends on the users using AWC, as in RAC users can edit properties and edit all the properties as they have to write access to the object. 

2. This option is best suitable if a number of groups and attributes are in control if the number of groups and attributes access increases this might cause overhead to configure and maintenance of the stylesheets.

Approach 3: 

1. for each such property we need to attach the property extension. 

2. For each new property we need to add a new property extension if the property is for a specific group. 

3. Code maintenance is overhead. 

In the given problem statement option 3 looks more logical as it can be extended easily i.e., for each new attribute just extension attachment and preference update. But in the end solution option to be implemented needs to be decided based on the real situation and complexity and customer choice as option 3 involves server customization. 

Blog by Avadhut Pujari.