I found this topic difficult and time consuming to research. There were plenty of hints how this could be utilised, but little information on what is possible and no working examples were demonstrated. So I will share, to help the next person looking for this information, or even just to make others aware this can provide viable solutions. I will demonstrate how I added two tables to the Controlled_Table table so that constraints could be leveraged against them to provide administrator access to Contacts without allowing full unrestricted administrator access.
Disclaimer: This is considered a customisation, and is not officially supported.
Background:
I found the need to have an analyst able to configure contacts, without being able to provide themselves or others with Administrator access. While it seemed I could enable this by customising forms for a unique form group, it appeared as if this would be more work than it should be to achieve what I wanted.
I sought a better way:
It was clear that the functional access for managing contacts is an all or nothing sort of deal, but I needed to enable only a small part of this access.
I did a lot of digging and research, and finally found my way to the Controlled_Table list. The list, out of the box, did not include tables such as Domain or usp_roles. Without these, you cannot control how the functional access "Security" - 'Modify' permissions manage roles and partitions, which includes assigning contacts to them.
Use Case:
Three things really need to be managed to prevent Administrator access for a contact.
Data Partition
Access Type
Roles
Access Type is managed by the grant level for a role, so can be controlled out of the box.
Data Partition and Roles need entries in the Controlled_Tables table to be targeted for refinement.
Constrains will need to be applied to the Roles. I prefer View constraints so they cannot be selected at any point. The constraint can be leveraged against the grant_level attribute of the usp_role table as this fit neatly with the model I am looking for.
Constraints will also need to be applied to the Domain. Again I chose view constraints. However, there is no access or grant level relationship for the data partitions. You could build some through the WSP as a new attribute, but I was looking to avoid using WSP to make this change, for now. I opted to include the list of non Administrator based Data Partitions.
A new Role, Data Partition and custom Tab view will need to be created to support this specialised role.
Procedure:
1. First, add the dmn and role tables to be controlled.
Run pdm_load on:
TABLE Controlled_Table
del desc obj_name sym
{ "0" ,"Data Partition" ,"dmn" ,"Domain" }
{ "0" ,"Role Table." ,"role" ,"usp_role" }
*SDM must be restarted before this can take effect.
2. Create a new Partition, configure as you see fit.
I copied from one of our level 1 support analyst partitions.
3. Create a new Constraint.
3.1. Data Partition is your new Partition
3.2. Table name = usp_role
3.3. Constraint type = View
3.4. Constraint:
grant_level <= 20
Note:Grant level of 30 is an Administrator, so it is excluded.
4. Create a new Constraint.
4.1. Data Partition is your new Partition
4.2. Table name = Domain
4.3. Constraint type = View
4.4. Constraint:
id IN (21700, 21701, 21800, 21801) OR id >= 400001 AND id <=400010 OR id >= 400012 AND id <=499999
*Example only, depends on your environment.
5. Create a new Role, configure as you see fit.
5.1. Ensure grant level is Analyst.
5.2. Link to the new Data Partition
Again, I copied from our level 1 support analyst roles.
6. Under 'Role Management', Create a new Menu Tree, Web form and Tab.
For Web form and Tab, I copied the existing admin form and tab. However I created a new Menu tree, so that it could be customised.
7. Customise the new Menu Tree by using the Customize Menu (When you view the Tree).
7.1. Remove anything that may exist under the tree name
7.2. Create a new node with the resource of "Contacts". Name as you like, but “Contacts” may be sufficient.
8. Edit your new Web form, and insert your new Tree Menu code name into the resource behind “tree_code=”.
$cgi?SID=$SESSION.SID+FID=123+OP=DISPLAY_FORM+HTMPL=admin_main_role.htmpl+KEEP.tree_code=z_NewAcctTree
9. Edit your new Tab, and change the “Starting page” to the new web form name.
10. Edit your new Role.
10.1. Change the Functional access under Additional Information > Functional access; Set “Security” to ‘Modify’. Ensure “Contact” is set to ‘Modify’.
10.2. Add the new tab under Resources > Tabs
11. Test, then assign the role to your choice of analyst.
What does this all do?
This created a method of constraining what roles and partitions that can be seen by the Analyst assigned to this role so that they can manage contacts under a custom menu tree that only allows them to search Contacts. This will allow them to manage all the attributes of a contact, but because they cannot see the Partitions or Roles for an Administrator, they cannot give Administrator access to themselves or another Analyst.
Note: While you do not need to have a customised menu tree to search, create and modify contacts as this is available from the Service Desk tab, you cannot copy an existing contact through this tab. The Contacts menu tree makes creating similarly configured contacts much quicker, which is much more productive for the new 'Contact Admin.'
Also note, if you have custom web form groups that prevent admin functions from being displayed or managed based on access type, you may need to create a new access type and include the id in your web form.
Any thoughts or questions?