I have come across such questions many a time as why do we use data/attribute restrictions instead of using conditional UI with our application designer restrictions. There are pros and cons of using both in our practice, and there is no wrong or right away of doing things, also different people will have different thoughts based on their experience. And, I am also writing this blog as per my experience or understanding.
As you all are aware that there are separate ways that can be used to set up condition UI in Maximo. Condition UI gives flexibility to change properties, give access or restrict data based on meeting or not meeting some condition. A developer also has the option to add and associate security options to tabs, sections, textboxes, tables etc., with a condition on top of the application security.
Let us start our explanation with a simple example. Let us suppose that my application has a text box, Status, which should be visible only to Management Group, Contractor Group, Labor group and HR group. I would go to application designer, create and associate a signature option to this text box. I would next go to Security Groups application, search for required groups, would navigate to Application tab and for my application I would give grant access to that signature option. I hope everybody would agree with me till this point.
Next, let us add some restriction(s) to the Status field, gradually. For HR group, the field should always be read-only. What could be a better approach to achieve this? I can go to application designer to access the application, open the text box properties dialog for that field where the signature option, created above, is already associated and click on Configure Conditional Properties. Select the HR group in Security Groups section, associate a condition which is always true (like 1=1) and for true condition enter a property=inputmode and value=readonly. As per my understanding, better way would have been to use a attribute restriction in the security groups application. In the Security Groups application, search for HR group, navigate to Data Restrictions tab, open Attribute Restrictions sub-tab. Select the object, attribute, application and keep the Type=READONLY.
Since this data restriction is enforced at the data level, this restriction will work for all instances of the object/attribute regardless of being instantiated through presentation (application UI), or via background process (such as action, or via integration). We need to remember that data restrictions always supersede application configurations in the Application Designer application. The flow of restrictions on an attribute starts with database configuration, then data restriction which is enforced at a security group level, and then Application Designer configurations which is only at the application's UI presentation level.
We also need to remember that configurations that are created through data restrictions are applicable wherever that object-attribute pair is used, while application designer restrictions are not. If you want to apply a restriction to a field in all the tabs of an application, it is advisable to use data restrictions as all the fields in all the tabs will inherit the restriction. However, if you configure restriction in application designer, it will have to be configured in each field of each tab. Similarly, for a table column, for header and detail section you will need to configure the same restriction twice in application designer.
Now, let us add some more interesting things to our Status field. Let us assume there is also a lookup for Status field with values, Inspected, Routed, Checked, Routed to Manager, In Progress, Approved, Completed. For Contractor and Labor group, the Status field should be required based on the value of some other field. Let us suppose that if the description field is not null and contains 'Test', the Status field should become required for Contractor and Labor group(s). But the Status field lookup should display only 'Inspected' and 'Routed' values to a contractor and only 'Checked' and 'Routed to Manager' values to a labor group member. Also, a labor group member should see all other values in the lookup if description field does not contain 'Test' but for a contractor group member no only two values should appear in the lookup at any time. We need not go explore conditional domains yet, let us save it for another day :)
Step 1: Create a condition TESTCOND in Conditional Expression Manager to check for value in description field of the same object.
Go to Security Groups application, search for Contractor group, navigate to Data Restrictions tab, open Attribute Restrictions sub-tab. Select the object, attribute, application, select the Type=REQUIRED and select Condition=TESTCOND. Repeat the same step for Labor group.
Step 2: Create two new lookups (CONTLOOKUP and LABLOOKUP) in Lookups.xml to display Inspected and Routed values and Checked and Routed to Manager values, respectively.
Go to Application Designer application, search for the application. Open text properties dialog for Status field where the signature option, created above, is already associated and click on Configure Conditional Properties. Select the Contractor group in Security Groups section, associate a condition which is always true (like 1=1) and for true condition enter a property=lookup and value=CONTLOOKUP. Similarly, add Labor group in Security Groups section, associate TESTCOND in Conditions section, for true condition enter a property=lookup and value=LABLOOKUP and for false condition enter a property=lookup and value=VALUELIST (if there is ALN/SYNONYM domain associated with STATUS attribute in database configurations).
I am not sure whether everyone would agree with me for the above approach I have considered. Let us consider another aspect of granting access to signature options. We had configured conditional UI for a section to become read-only on meeting some condition for say, Labor Group. But this section needs to be visible to Management Group and HR Group but this section need not be available to Contractor group at all. As you all have figured out already, we have associated a signature option to this section and configured conditional properties for Labor group with a condition and have set property=inputmode and value=readonly for when condition is true. And, in Security Groups application, for this application and this signature option, we granted access to Management Group and HR Group but did not grant access to Contractor Group.
Here I usually need to answer very often why do we need to go to each security group to grant access? We can configure conditional UI for rest of the groups as well. For Management and HR Group(s) who already have this application access, we can also configure conditional properties for the section mentioned above by associating a always true condition with property=display and value=true. For contractor group, we can configure conditional properties for this section by associating a always true condition with property=display and value=false.
We do get into some more confusions with independence or dependence of security groups. There is very useful (or rather sometimes confusing) check box provided in Security Groups application as 'Independent of Other Groups'. We will keep multi-site implementations for some other time, we will focus on single-site implementations for today. The purpose of this particular checkbox is to decide whether access rights of this group can be merged with the access rights of other groups. This is very useful and applicable to multi-site implementations and does not hold much significance for single site implementations.
Let us consider a single site (SITE-A) implementation where a user belongs to two security groups, say Management and HR. Management group has access to Purchase Orders application and HR group has access to People application. Let us also consider that Management Group is set up with No Site information and HR Group is set up with SITE-A in a single site implementation. If we make both the sites independent then this user will have access only to People application. If we do not check 'Independent of Other Groups' checkbox for these two groups, the user will have access to both the applications. As a best practice, we should not check this checkbox for single site implementations.
If we have multiple independent security groups then the resulting security profile of the user gets difficult to determine if the user belongs to more than one security group. Let us extend our example further. Say user USER1 belongs to both HR and Contractor group(s). HR and Contractor groups are both independent and are implemented with SITE-A (or authorized for all sites). Both groups are implemented with access to Purchase Contracts application but have been configured with specific conditional access to change status. Say, contractor should be able to change the status of a purchase contract record on meeting condition X and HR should be able to change the status of a purchase contract record on meeting condition Y. If either of the condition X or Y is true, USER1 user will be able to change status of the purchase contract. If there is some user USER2 who belongs to Contractor group alone and user USER3 who belongs to HR group alone, then USER 2 will be able to change the status of a purchase contract record when condition X is true and USER3 will be able to change the status when condition Y is met.
If we clear the checkbox and make the contractor group dependent, what will happen to the privileges for USER1? In this case, USER1 will be able to change the status of Purchase Contract record when condition X is true.
Please feel free to post your views and comments on this blog. I would love to hear from you.
Since this data restriction is enforced at the data level, this restriction will work for all instances of the object/attribute regardless of being instantiated through presentation (application UI), or via background process (such as action, or via integration). We need to remember that data restrictions always supersede application configurations in the Application Designer application. The flow of restrictions on an attribute starts with database configuration, then data restriction which is enforced at a security group level, and then Application Designer configurations which is only at the application's UI presentation level.
We also need to remember that configurations that are created through data restrictions are applicable wherever that object-attribute pair is used, while application designer restrictions are not. If you want to apply a restriction to a field in all the tabs of an application, it is advisable to use data restrictions as all the fields in all the tabs will inherit the restriction. However, if you configure restriction in application designer, it will have to be configured in each field of each tab. Similarly, for a table column, for header and detail section you will need to configure the same restriction twice in application designer.
Now, let us add some more interesting things to our Status field. Let us assume there is also a lookup for Status field with values, Inspected, Routed, Checked, Routed to Manager, In Progress, Approved, Completed. For Contractor and Labor group, the Status field should be required based on the value of some other field. Let us suppose that if the description field is not null and contains 'Test', the Status field should become required for Contractor and Labor group(s). But the Status field lookup should display only 'Inspected' and 'Routed' values to a contractor and only 'Checked' and 'Routed to Manager' values to a labor group member. Also, a labor group member should see all other values in the lookup if description field does not contain 'Test' but for a contractor group member no only two values should appear in the lookup at any time. We need not go explore conditional domains yet, let us save it for another day :)
Step 1: Create a condition TESTCOND in Conditional Expression Manager to check for value in description field of the same object.
Go to Security Groups application, search for Contractor group, navigate to Data Restrictions tab, open Attribute Restrictions sub-tab. Select the object, attribute, application, select the Type=REQUIRED and select Condition=TESTCOND. Repeat the same step for Labor group.
Step 2: Create two new lookups (CONTLOOKUP and LABLOOKUP) in Lookups.xml to display Inspected and Routed values and Checked and Routed to Manager values, respectively.
Go to Application Designer application, search for the application. Open text properties dialog for Status field where the signature option, created above, is already associated and click on Configure Conditional Properties. Select the Contractor group in Security Groups section, associate a condition which is always true (like 1=1) and for true condition enter a property=lookup and value=CONTLOOKUP. Similarly, add Labor group in Security Groups section, associate TESTCOND in Conditions section, for true condition enter a property=lookup and value=LABLOOKUP and for false condition enter a property=lookup and value=VALUELIST (if there is ALN/SYNONYM domain associated with STATUS attribute in database configurations).
I am not sure whether everyone would agree with me for the above approach I have considered. Let us consider another aspect of granting access to signature options. We had configured conditional UI for a section to become read-only on meeting some condition for say, Labor Group. But this section needs to be visible to Management Group and HR Group but this section need not be available to Contractor group at all. As you all have figured out already, we have associated a signature option to this section and configured conditional properties for Labor group with a condition and have set property=inputmode and value=readonly for when condition is true. And, in Security Groups application, for this application and this signature option, we granted access to Management Group and HR Group but did not grant access to Contractor Group.
Here I usually need to answer very often why do we need to go to each security group to grant access? We can configure conditional UI for rest of the groups as well. For Management and HR Group(s) who already have this application access, we can also configure conditional properties for the section mentioned above by associating a always true condition with property=display and value=true. For contractor group, we can configure conditional properties for this section by associating a always true condition with property=display and value=false.
We do get into some more confusions with independence or dependence of security groups. There is very useful (or rather sometimes confusing) check box provided in Security Groups application as 'Independent of Other Groups'. We will keep multi-site implementations for some other time, we will focus on single-site implementations for today. The purpose of this particular checkbox is to decide whether access rights of this group can be merged with the access rights of other groups. This is very useful and applicable to multi-site implementations and does not hold much significance for single site implementations.
Let us consider a single site (SITE-A) implementation where a user belongs to two security groups, say Management and HR. Management group has access to Purchase Orders application and HR group has access to People application. Let us also consider that Management Group is set up with No Site information and HR Group is set up with SITE-A in a single site implementation. If we make both the sites independent then this user will have access only to People application. If we do not check 'Independent of Other Groups' checkbox for these two groups, the user will have access to both the applications. As a best practice, we should not check this checkbox for single site implementations.
If we have multiple independent security groups then the resulting security profile of the user gets difficult to determine if the user belongs to more than one security group. Let us extend our example further. Say user USER1 belongs to both HR and Contractor group(s). HR and Contractor groups are both independent and are implemented with SITE-A (or authorized for all sites). Both groups are implemented with access to Purchase Contracts application but have been configured with specific conditional access to change status. Say, contractor should be able to change the status of a purchase contract record on meeting condition X and HR should be able to change the status of a purchase contract record on meeting condition Y. If either of the condition X or Y is true, USER1 user will be able to change status of the purchase contract. If there is some user USER2 who belongs to Contractor group alone and user USER3 who belongs to HR group alone, then USER 2 will be able to change the status of a purchase contract record when condition X is true and USER3 will be able to change the status when condition Y is met.
If we clear the checkbox and make the contractor group dependent, what will happen to the privileges for USER1? In this case, USER1 will be able to change the status of Purchase Contract record when condition X is true.
Please feel free to post your views and comments on this blog. I would love to hear from you.
