UserCriteria - Server side script evaluation

[Jared Healy2]

This new feature seems to be very poorly documented in the wiki. I'm hoping someone out there has figured this out or gotten information on it.

Wiki article: http://wiki.servicenow.com/index.php?title=User_Criteria#gsc.tab=0

The only other thing that seems like it might be related: http://wiki.servicenow.com/index.php?title=CriteriaEvaluator#gsc.tab=0

The use case is custom CMS pages. How do we evaluate user criteria in Jelly to determine if a user can see a particular catalog item or category? It seems like the CriteriaEvaluator does something like that but I'd have to write my own wrapper for it to loop through and add all the items and then test a match to the current user. Is there already a script include or evaluation that I can leverage?

Where I am seeing the issue is utilizing the below code results in evaluating to true for everything even though on the native catalog page they can't see the records.

var ci = GlideappCatalogItem.get(featured_item.sys_id);
if(ci.isVisibleStandalone() && ci.canView()){
         // Do stuff
}

Are there new functions or classes that leverage the User Criteria?

The second issue/question I have is around the actual security of this method. From my testing, it appears that if you have a direct link to an item, you can still navigate to it and submit it. The User Criteria "security" appears to only prevent you from displaying in the catalog. Now since it's internal maybe there is no issue, but lets say you had an existing item that you wanted to further restrict but users had book marked it. They could still navigate to it and submit it. And this is all SN supported bookmarks using their side bar since you can drag catalog items there.

Further comment / complaint: There is no debug capability. Every other security method has debug around it where you can at least generate some output to see what is blocking you when you impersonate a user. For User Criteria there is nothing. For larger organizations or MSP you could easily have a very large rule table. There's no way to systematically trouble shoot User Criteria.

[Valor1]

Are you an admin when you're testing this? If so, try impersonating and report back the results?

[Jared Healy2]

Yes, I am the admin. I'm testing impersonating a few user types. From everything I've tested so far, the User Criteria are a a UI filtering mechanism that is ONLY applied on native SN Catalog pages. It is NOT a security method as far as my testing shows. As a user that is restricted from access by a User Criteria I can navigate directly to any category or catalog item.

I ended up writing a script include and corresponding Before Query Business Rules on both the sc_category and sc_cat_item tables that determines all User Criteria that match the current logged in user and adds query parameters to limit the result set to only the items I have access to see.

The basic test is in CMS to create a list block querying the sc_category table. Impersonate a user that is not allowed to see any Categories and then view a page with that list block attached. They can see all the contents of the categories and they should not. The same is true for catalog items.

[Daniel Pettet · Accepted solution]

I experienced this problem today. The tricky bit is the context.

When calling the function from g:evaluate or a script include it won't work. When running it within a JEXL expression it will.

JEXL is the ${...} or $[...] stuff (depending on phase 1 and 2).

Eg.

<j:while test="${req.next()}">
   <j:if test="${GlideappCatalogItem.get(req.sys_id).canView() == true}">
       ${req.name} : ${req.short_description}
   </j:if>
</j:while>

This works in Fuji.

NOTE that "available for" and "not available for" options work a little strangely. I believe that "not available for" should only be used in combination with "available for". If you are testing something out then always work with a simple "available for" record first.

[danpatino]

I'm using this same approach in a CMS I'm building (GlideappCatalogItem.get(req.sys_id).canView() to evaluate whether a user is allowed to see a catalog item).   It's evaluating permissions correctly but for some reason it's returning 'false' for record producers and only for non-roled users.

Anyone have any ideas why that would happen?