Hi all,
I am looking for SN admins who may have experienced something similar with the newer conditional_table_query_range ACLs.
During an upgrade to Australia, ServiceNow inserted a new ACL on our instance:
- Name = cmdb_ci
- Operation = conditional_table_query_range
- Type = record
Audit history shows that the ACL was created by platform processes (glide.maint / System) and was marked as auto-generated. No administrator created or modified this ACL.
After upgrade the 3 patched came from SN.
What makes this interesting is the upgrade history.
For the same ACL I can see:
- First upgrade: Inserted (ACL not active)
- Subsequent Australia patches: Skipped (patch tried to change value to Active = true)
- Subsequent Australia patches: Skipped (patch tried to change value to Active = true)
- Subsequent Australia patches: Skipped (patch tried to change value to Active = true)
Version history shows:
- Current version source = Update Set: Default
- Newer versions delivered by Australia patches exist
- Newer patch versions remain History
- Default remains Current
Upgrade History classifies the record under Customizations Unchanged and Upgrade Details show Disposition = Skipped.
Because of that, newer patch versions of the ACL never become current (and is still not active).
The ACL was not modified by a customer, yet patches behave as if it is a customer customization.
The issue became visible while investigating Query Range security changes. One of the related ACLs contains a condition similar to: SAB_xxxxx=true^UserIsAuthenticated=true^HasRightsToReadIsTrue=true
And this is the issue - ACL conditional_table_query_range is not active and always return false to ACL query_range.
where the SAB_* attribute resolves to a conditional_table_query_range ACL check.
Has anyone seen conditional_table_query_range ACLs inserted during an upgrade and then skipped by subsequent patches because of system updates?
