Customized base roles: a good idea or not?

Question

I'm thinking about creating copies of the default base roles that will be customized to support certain use cases. Primairly these custom base roles wil be more restrictive than the default base roles. 
 Per default the system assigns these primary base application roles/permission groups to persons/managers. Everyone (Change)\VI_4_ALLUSER Everyone (Lookup)\VI_4_ALLUSER_LOOKUP Managers of identities\VI_4_ALLMANAGER 
 For example: OOTB a manager can edit the personal data of his direct reports. 
 If you don't want managers to edit the personal data of reports or want to hide certain data or employees based on there status. Then you can configure this on the API server level via the Administration Portal: API method configuration. (P.s. this configuration option doesn't work properly in 92, so I'm waiting for a fix or 9.3) Or you can configure your Angular project to hide things in the front-end. 
 So from my standpoint what if I would make a copy of the role of 'Managers of identities\VI_4_ALLMANAGER' and remove the permissions I don't need: 'Managers of identities (Limited access)\CCC_4_ALLMANAGER_Limited' 
 Then I would have the most flexibility and it's implemented on the lowest security level the database. Managers that need to edit personal data can remain assigned to: 'Managers of identities\VI_4_ALLMANAGER' Managers that don't need to edit personal data are assigned to: 'Managers of identities (Limited access)\CCC_4_ALLMANAGER_Limited' 
 I understand that this customization would have major impact on OOTB configuration and needs the be maintained, and tested thoroughly after updating or applying hotfixes. 
 I would appreciate some feedback/experience on this topic. 
 Thank you, Niels

Jos Groenewegen · Accepted Answer

Hi Niels, 
 Having run into similar issues in quite a few places here are my thoughts (take them for what they're worth obviously ;) )... 
 1) I agree limiting access in the permission layer is what you want to do. If you don't you always run the risk of people still getting access or being able to change data through 'some' new method. Be it API's you make available or new screens that don't exist yet. So yes, the permission layer is where you want to limit the access. 
 2) When limiting access be aware that (especially if you remove read access to information) you still want to remove things from the front-end as well. Otherwise you'll get lots of 'no access' to information issues etc. So, you will still want to hide things in the front-end as well. 
 
 -- 
 Then, some experience from having done this; 
 Yes obviously you'll want to (re) test things after new deployments but generally it isn't too bad. Just realize that whenever a new release or patch comes out you'll want to check all the schema changes, see if the 'old' roles have permissions on these and if so add them to your new custom roles. 
 
 I do recommend exporting and loading in the permissions using (for example) the data importer or if you want to be more modern an API. Although it can be done through the GUI in my experience that's a pain and in the end... It is all just entries in the database :).

Customized base roles: a good idea or not?

Top Replies