Question
IKOR PX
AU
Last activity: 29 Sep 2020 7:24 EDT
OOTB roles - To Clone or not to clone
Hey Team..
I wanted to discuss the Pega best practice of OOTB role cloning.. E.g. PegaRULES:WorkMgr4.
What do you think? Should we clone it to app specific role? or should we just use this as a dependent role for an app specific role? On a high level I see that if we clone - less dependency on Pega product changes in future. If we do not clone - More dependency on Pega product changes in future - the role may change or new role may replace this - we need to factor in for good amount of testing at that time. But isn't this all part of the product upgrade?
I mean we aren't cloning the Pega platform anticipating that Pega might change a lot of underlying rules in future releases! Similarly, I guess we need not clone the OOTB roles.. Has any one come across a situation that negates this idea?
Accepted Solution
Updated: 29 Sep 2020 7:24 EDT
Pegasystems Inc.
AU
As a general rule I look to take a path in Pega that does not involve cloning. Dependent Roles give me that path in Pega Access Control design.
You are correct to mention upgrade as an important consideration. Consider that, in future releases of Pega Platform, there are likely new capabilities available to the Work Manager Portal whose visibility is driven by privileges.
- If your Access Groups reference a role - say MyApp:WorkMgr4 - which was cloned from PegaRULES:WorkMgr4 in a past version of Pega, those Access Groups don't see any of the new capabilities delivered to that PegaRULES:WorkMgr4 when you upgrade Pega.
- If however MyApp:WorkMgr4 is configured to be dependent on PegaRULES:WorkMgr4, MyApp:WorkMgr4 observes the changes delivered in the upgraded PegaRULES:WorkMgr4 and is more likely to behave as expected in the upgraded Work Manager Portal.
If there is access granted by PegaRULES:WorkMgr4 that you want to lock down in MyApp:WorkMgr4, then an Access of Role To Object (ARO) you implement on MyApp:WorkMgr4 can overrides the ARO for the same Class on its Dependent Roles. This way the AROs you see listed on MyApp:WorkMgr4:
As a general rule I look to take a path in Pega that does not involve cloning. Dependent Roles give me that path in Pega Access Control design.
You are correct to mention upgrade as an important consideration. Consider that, in future releases of Pega Platform, there are likely new capabilities available to the Work Manager Portal whose visibility is driven by privileges.
- If your Access Groups reference a role - say MyApp:WorkMgr4 - which was cloned from PegaRULES:WorkMgr4 in a past version of Pega, those Access Groups don't see any of the new capabilities delivered to that PegaRULES:WorkMgr4 when you upgrade Pega.
- If however MyApp:WorkMgr4 is configured to be dependent on PegaRULES:WorkMgr4, MyApp:WorkMgr4 observes the changes delivered in the upgraded PegaRULES:WorkMgr4 and is more likely to behave as expected in the upgraded Work Manager Portal.
If there is access granted by PegaRULES:WorkMgr4 that you want to lock down in MyApp:WorkMgr4, then an Access of Role To Object (ARO) you implement on MyApp:WorkMgr4 can overrides the ARO for the same Class on its Dependent Roles. This way the AROs you see listed on MyApp:WorkMgr4:
- When dependent on PegaRULES:WorkMgr4: Represent only those AROs you need to newly introduced for your functionality in MyApp, as well as those that you consciously introduce to override that which you don't want from the dependent roles.
- When cloned from PegaRULES:WorkMgr4: Show every ARO that applies for the Role: those cloned & unchanged, those cloned and slightly modified, and those newly introduced.
The maintenance effort - on upgrade and in general - is easier when using Dependent Roles as it is clearer what you intend MyApp:WorkMgr4 to do that is different from OOTB WorkMgr4.
Dependent Roles was introduced into CLSA as of Pega 8.3 along with Privilege Inheritance - review the module here for more details and scenarios:
https://academy.pega.com/module/defining-authorization-scheme/v1/in/11776
Pegasystems Inc.
FR
Hello,
Can this be helpful: https://collaborate.pega.com/question/work-groups-access-groups-roles
Accepted Solution
Updated: 29 Sep 2020 7:24 EDT
Pegasystems Inc.
AU
As a general rule I look to take a path in Pega that does not involve cloning. Dependent Roles give me that path in Pega Access Control design.
You are correct to mention upgrade as an important consideration. Consider that, in future releases of Pega Platform, there are likely new capabilities available to the Work Manager Portal whose visibility is driven by privileges.
- If your Access Groups reference a role - say MyApp:WorkMgr4 - which was cloned from PegaRULES:WorkMgr4 in a past version of Pega, those Access Groups don't see any of the new capabilities delivered to that PegaRULES:WorkMgr4 when you upgrade Pega.
- If however MyApp:WorkMgr4 is configured to be dependent on PegaRULES:WorkMgr4, MyApp:WorkMgr4 observes the changes delivered in the upgraded PegaRULES:WorkMgr4 and is more likely to behave as expected in the upgraded Work Manager Portal.
If there is access granted by PegaRULES:WorkMgr4 that you want to lock down in MyApp:WorkMgr4, then an Access of Role To Object (ARO) you implement on MyApp:WorkMgr4 can overrides the ARO for the same Class on its Dependent Roles. This way the AROs you see listed on MyApp:WorkMgr4:
As a general rule I look to take a path in Pega that does not involve cloning. Dependent Roles give me that path in Pega Access Control design.
You are correct to mention upgrade as an important consideration. Consider that, in future releases of Pega Platform, there are likely new capabilities available to the Work Manager Portal whose visibility is driven by privileges.
- If your Access Groups reference a role - say MyApp:WorkMgr4 - which was cloned from PegaRULES:WorkMgr4 in a past version of Pega, those Access Groups don't see any of the new capabilities delivered to that PegaRULES:WorkMgr4 when you upgrade Pega.
- If however MyApp:WorkMgr4 is configured to be dependent on PegaRULES:WorkMgr4, MyApp:WorkMgr4 observes the changes delivered in the upgraded PegaRULES:WorkMgr4 and is more likely to behave as expected in the upgraded Work Manager Portal.
If there is access granted by PegaRULES:WorkMgr4 that you want to lock down in MyApp:WorkMgr4, then an Access of Role To Object (ARO) you implement on MyApp:WorkMgr4 can overrides the ARO for the same Class on its Dependent Roles. This way the AROs you see listed on MyApp:WorkMgr4:
- When dependent on PegaRULES:WorkMgr4: Represent only those AROs you need to newly introduced for your functionality in MyApp, as well as those that you consciously introduce to override that which you don't want from the dependent roles.
- When cloned from PegaRULES:WorkMgr4: Show every ARO that applies for the Role: those cloned & unchanged, those cloned and slightly modified, and those newly introduced.
The maintenance effort - on upgrade and in general - is easier when using Dependent Roles as it is clearer what you intend MyApp:WorkMgr4 to do that is different from OOTB WorkMgr4.
Dependent Roles was introduced into CLSA as of Pega 8.3 along with Privilege Inheritance - review the module here for more details and scenarios:
https://academy.pega.com/module/defining-authorization-scheme/v1/in/11776