• State Verified Answer
  • Replies 5 replies
  • Subscribers 95 subscribers
  • Views 335 views
  • Users 0 members are here
Options
Related

Customized base roles: a good idea or not?

Niels de Groot
5 months ago

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

Parents
  • 0 5 months ago

    Having done this in the past at several implementations I can say a few things;

    1) Conceptually I fully agree with you, you want to limit permissions at the lowest level possible. This means at the permission group, otherwise new screens can always pop-up (or requests can be placed directly to an API) allowing data changes you don't want.

    2) When you make fully custom permission groups (as you already noted) be aware these need to be updated with every patch / version of the system where tables are added. (Ideally, automate the tests for that ;) )

    Having done it a few more recommendations I would say (based on personal experience...);

    -Seriously consider exporting + importing the permissions on your new groups. In the end these are all record stored in the database and putting them in using a data import was (at least in the past) a lot easier than adding it all through the GUI.

    -When you remove the permissions you will still have to change things in your front-end. As long as you leave read access on a field it isn't too bad, but especially if view permissions are removed you get a lot of hidden fields. So yes remove it from the permission model, but go through the front-end as well.

Reply
  • 0 5 months ago

    Having done this in the past at several implementations I can say a few things;

    1) Conceptually I fully agree with you, you want to limit permissions at the lowest level possible. This means at the permission group, otherwise new screens can always pop-up (or requests can be placed directly to an API) allowing data changes you don't want.

    2) When you make fully custom permission groups (as you already noted) be aware these need to be updated with every patch / version of the system where tables are added. (Ideally, automate the tests for that ;) )

    Having done it a few more recommendations I would say (based on personal experience...);

    -Seriously consider exporting + importing the permissions on your new groups. In the end these are all record stored in the database and putting them in using a data import was (at least in the past) a lot easier than adding it all through the GUI.

    -When you remove the permissions you will still have to change things in your front-end. As long as you leave read access on a field it isn't too bad, but especially if view permissions are removed you get a lot of hidden fields. So yes remove it from the permission model, but go through the front-end as well.

Children
No Data