
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-16-2022 02:02 PM
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:
-
- snc_internal, where new ApproverUtils().canApproversRead();
- snc_internal, where gs.getProperty('glide.sm.default_mode') == 'allow'
- admin
- public, where gs.getProperty('glide.sm.default_mode') == 'allow' AND GlidePublicPage.isPublic(current.getTableName()
- 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)?
Solved! Go to Solution.
- Labels:
-
Multiple Versions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-16-2022 03:32 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-16-2022 03:32 PM
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-20-2022 07:41 AM
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.