Looking for a better way to clean up Acess of Role to Object rules related to a specific access role
Yesterday we found a mismatch in an access role in one of the test environments. We didn't quickly see the difference so decided to just redeploy the ARO rules from the development environment to the test environment. As there might be some ARO rules on the target system that might not exist on Dev anymore, we decided to first clean up the existing ARO rules with a specific access rule, and then to redeploy the access role with ARO rules.
One of the options here is to manually delete the ARO rules by hand but as there are 60 of them this is not really efficient. The alternative is to remove this directly from the DB in the pr4_rule by filtering on the access role name. We did this alternative, but it would be better to have an easy way to do this from Designer Studio.
Does anyone know an easy way to clean up the ARO rules particular to a certain Access Role?
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Until Pega 7.1.6 in order to delete ARO(Access of Role to Object) from Access Role, we need to delete ARO manually. But, from Pega 7.1.7 in Access Role rule a delete option has been included for every ARO, where we can directly delete ARO from Access Role instead of deleting it manually.
You can also try deleting the ARO from the Role Names landing page as shown below. Role Names landing page will display the list of Access Roles available in the system, upon choosing the specific Access Role it will be displayed in the editable mode where there was a option to delete the selected ARO.
in your response you're actually mentioning the delete-option from the Access Role. This is manual as with an access role with 40 classes (ARO's), you need to delete them all seperately manually. That is not really workable and a delete from DB directly is more preferable IMO (although directly working on the DB should not be preferred). The second option you're mentioning is just another way to open the Access Role in a tab right? I don't see this option as a workable option.