How do you clear the user criteria cache

[justin_anonuevo]

Question: How do you clear the cache for user criteria in Service Portal for catalog items that should be restricted via the category. I assume it would be gs.cacheFlush("something");, I just dont know what that something is. 

Context: We have a bunch of catalog items in categories that have a script based user criteria. All works fine and well for a while. Then everyone starts seeing items they should not see. I have tried cache.do, it didn't work, including with logging out and back in as the target user, no impersonation. I have added debug statements in the criteria, they show up (so it is being evaluated), once, and the criteria return false as expected. And yet the user could still see the catalog items. 

If we remove the user criteria from the category and readd them (same criteria, no other changes), the issue is resolved. In that process, ServiceNow triggers a bunch of cache clears, which show up in the cache flush history. Specifically it clears:

criteria_cache_mtom

USER_CATEGORIES_CACHE

USER_ITEMS_CACHE

ZZ_CATALOG_ITEM_CACHE_YY

ZZ_CATEGORY_CACHE_YY

ZZ_CATITEM_CATEGORIES_CACHE_YY

ZZ_CATALOG_CACHE_YY

So it is clearing the cache, and that is fixing the issue. 

We have also set 

glide.cache.disabled.criteria_cache = true

glide.cache.disabled.user_items_cache = true

glide.cache.disabled.scripted_user_criteria_cache = true

Cleared Cache, didnt work

[Allen Andreas]

Hello,

It doesn't really make sense that it works fine for a while...then all of a sudden people start seeing stuff they shouldn't unless the scripted user criteria is not for something that is more permanently set.

If your user criteria is more dynamic, meaning it could change for a user more often...then yeah, your only options are to set system properties like: 

glide.cache.disabled.criteria_cache
glide.cache.disabled.user_items_cache

to true. Setting those to true will disable caching on user criteria in general and then disable caching which users have access to which catalog items, meaning every time they try to go to view the catalog, it'll run the user criteria right then to check. Both of those are a slight hit on performance.

If you're still having trouble, then I would reach out to ServiceNow Support as literally setting those two system property eliminates the system caching any of that. Alternatively, I'd recommend reviewing your approach to the user criteria that was set and consider another path with the logic.

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

[michaelward]

I tested this in a Washington Patch 7 release and found the two properties do not change the effect of the cache.  In other words, I can set these properties to true, change my 'condition' for which a scripted user criteria grants or does not grant access to an article viewed on the kb_article page, and there is no difference.  I still have to logout/login in order to see the KB article viewed, or not allowed to view.  In my use case, I have a simple sys_user field on which the user criteria is based.  At the end of the day, there seems to be no way around needing to login/logout.  So given the ServiceNow user criteria cache design, I would go as far as stating that user criteria cannot be used for dynamic conditions for securing content like articles.  My alternative is to use AI Search Topics to refine searching for the articles by that same sys_user field value.  Unfortunately, this is not a security restriction ( a client requirement ), but just a filter condition.  Besides, I don't like the performance impact the dynamic user criteria could have on browsing dynamic topic pages in EC portal, and using it, or something like before query business rules just make me cringe.  Imagine thousands of KB articles in a taxonomy being evaluated every time with no cache.  I may investigate the use of ACLs for my use case.  

[justin_anonuevo]

Good KB Article. Thank you.

Our use case is users have a custom field on their record that stores some extra meta data to determine what they should see in platform (primary support group for that user). That data would only change on hiring or ending a job, so it doesn't change often at all. So in the case where users start to see everything, what they should have seen should not have changed at all, probably in years. So a cache like stated in the article would work perfectly well. And yet we see what we see and the fix makes no material change (just remove and re-add the same thing) to what they should see, other than triggering a cache clear.

In the future, I think there are better ways to structure our data in platform (this is legacy functionality, but huge value), but as is the case with business, you cannot just up and change things on a whim, especially if the outcome is "no new features" and it has a high cost. Double especially if it is using a feature that is supposed to work.