How to provide read access ACL to sc_multi_row_question_answer?

dsavant
Kilo Expert

Out of the box, there is just one report-view ACL for sc_multi_row_question_answer but we have an integration that requires read access to the table. When attempting to add a new read ACL for sc_multi_row_question_answer, the system indicates (4) existing ‘*’ ACLs will be masked:

    1. snc_internal, where new ApproverUtils().canApproversRead();
    2. snc_internal, where gs.getProperty('glide.sm.default_mode') == 'allow'
    3. admin
    4. public, where gs.getProperty('glide.sm.default_mode') == 'allow' AND GlidePublicPage.isPublic(current.getTableName()
    5. Note: glide.sm.default_mode is set to 'deny' on our instances

Will proceeding with the update prevent access to sc_multi_row_question_answer for snc_internal (ACL #1) or admin *ACL #3)?

1 ACCEPTED SOLUTION

Tony Chatfield1
Kilo Patron

Hi, creating new table or field specific ACL's does not impact existing table\field specific ACL's, but it will 'mask' generic wildcard '*' ACL's for the table\field.

  • If you are adding a field specific acl, then any existing generic rules will no longer be considered for the field, and without this behaviour it would not be possible to control any access as the OOB '*' rule would over rule all ACL's

Based on your scenario, if you have added a field specific ACL but also want the existing '*' access to be true, then I would think that you will need to create additional field specific rule(s) that match the '*' card rule(s) being masked, or you can potentially roll all your access requirements up into 1 specific rule.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0541355

 

 

View solution in original post

2 REPLIES 2

Tony Chatfield1
Kilo Patron

Hi, creating new table or field specific ACL's does not impact existing table\field specific ACL's, but it will 'mask' generic wildcard '*' ACL's for the table\field.

  • If you are adding a field specific acl, then any existing generic rules will no longer be considered for the field, and without this behaviour it would not be possible to control any access as the OOB '*' rule would over rule all ACL's

Based on your scenario, if you have added a field specific ACL but also want the existing '*' access to be true, then I would think that you will need to create additional field specific rule(s) that match the '*' card rule(s) being masked, or you can potentially roll all your access requirements up into 1 specific rule.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0541355

 

 

Thanks Tony, adding new ACLs that mirrored the existing '*' for the sc_multi_row_question_answer table opened access for the our role while preserving access for the out-of-the-box roles. 

Of course there were subordinate references that also needed to be opened for:

  • item_option_new (Variable)
  • question_answer (Question Answer)
  • item_option_new_set (Variable Set)

Appreciate the confirmation.