Enable read access to configure > security rules from context menu

Kumar38
Kilo Sage

I need to enable users with a certain role to be able to look at ACLs on that current table using configure > Security Rules. They need read only access

 

There is a UI Macro "context_form_header" with the following line , hence I created a Write ACL with  type = ui_page and operation = write and name = configure.personalize_security. 

 

<g:evaluate var="jvar_personalize_security" expression="gs.hasRightsTo('ui_page/configure.personalize_security/write', null)" />
 
However It didn't work. updated the same ACL to read access , still user cant see the security rules from configure
 
<g:evaluate var="jvar_personalize_security" expression="gs.hasRightsTo('ui_page/configure.personalize_security/read', null)" />
3 REPLIES 3

Mark Manders
Tera Patron

First: why? What is your use case? There are many, many ACLs in the system, containing scripts, security attribute and roles. Those also come from different tables (like sys_security_acl_role).  You would need to add a lot, just to get this done for that role. 

 

Check the read ACLs on the ACL table. That's probably what's blocking the access. Have you considered granting them the access_analyzer_admin role? That will grant them read access to ACLs (OOB) and also allows to analyze the access, instead of only looking at ACLs, without seeing everything.

Kumar38
Kilo Sage

I granted read access to both sys_security_acl and sys_security_acl_role tables. They can see the data if I share the ACL(sys_security_acl ) table link with them.

However they cant see ACLs, when doing configure > Security rules on the table that they want to look at . This is for Audit reasons.

My last resort is to enable access to ACL module in left nav, if the configure > security rules cant be enabled to certain roles as the team needs it for auditing purposes without reaching out to a dev

Why not give the auditors separate accounts to access the instance the moment the want to audit? Add those accounts to a separate group with both the admin AND the read_only role. They will be able to see the ACLs (and everything else), but won't be able to change anything.