Different portal search results between users

eduque
Giga Expert

Hi everyone, I've been trying to troubleshoot this all morning and can't figure it out. Hopefully you can see how much I've tried to figure it out myself before asking for help, so any helping hand would be wonderful. Since "Debug security" doesn't work with portals, it's been very difficult to identify.

In our Service Portal, when a user searches for a term (in the below example, the term "trash"), they are supposed to see two results, one from a knowledge article and one from a facilities catalog (a service catalog). (FYI, the search widget being used is the homepage search widget, which calls the typeahead search widget)

Correct:

find_real_file.png

I have admin rights, but when I impersonate another user that doesn't have admin rights. all they see is this:

find_real_file.png

You can see that the Service Catalog item disappears from the search result.

Here is some additional information that I've been able to establish in my attempts to debug:

  • If I add "catalog_admin" role to a user, they now get access to both results.
    • If I add the roles that Catalog_admin contains (image_admin, catalog, and user_criteria_admin) but not catalog_admin, they do NOT see the correct results, so the user must have at least the "catalog_admin" role
    • The correct result only appears after I re-impersonate them, eg. I'm impersonating someone, then give them the catalog_admin role, I first have to impersonate someone else, then impersonate the new catalog_admin before I can refresh and see the correct result
  • The catalog that the portal is configured to is the Facilities Catalog, not the default Service Catalog.
    • find_real_file.png
    • If I change the catalog to Service Catalog, then users indeed can successfully search for items in the service catalog, but not the facilities catalog. This shows that users can see the default's catalog items when that's the catalog set, but cannot see facilities catalog items when the facilities catalog is set.
  • I have hundreds of ACLs that start with sc_ and I do not know what combination of which ones are controlling this.
  • I can't seem to find any scripts in the widget that are validating security, but I might be wrong

Help?

1 ACCEPTED SOLUTION

eduque
Giga Expert

I figured it out, I ended up going through every ACL that starts with sc_, was active, and was a read operation. Anything that had the role "catalog_admin" i changed to public, one at a time. It finally started working on the last one I changed over, which then meant it could have been any combination of the ones I turned on. So I turned each one off one by one to make sure it still worked.



Here is the culprit:


sc_cat_item_producer [read]



change catalog_admin to public or something and it'll work.



I'm going to take a nice long nap now.


View solution in original post

6 REPLIES 6

Goran WitchDoc
ServiceNow Employee
ServiceNow Employee

Can the user browse through the Catalog and see the items? What I mean is that is it only in search it isn't visible or perhaps you don't have a catalog where they can click around in?



//Göran


The user can see all the catalog items in ServiceNow, and they previously weren't able to see catalog items in the portal but there was a specific line of code in the SC Category Page widget that was checking for an ACL that I commented out that allowed users to see the items:


//if (!$sp.canReadRecord("sc_cat_item", sc.sc_cat_item.sys_id.getDisplayValue()))


// continue;


if you are removing restriction on page level then i think you should remove it on search level also.



update your search source..n comment out highlighted line n try.



find_real_file.png



(please mark helpful/like/correct if it helps)


I did actually try that earlier and that didn't seem to do anything. Thanks for the suggestion though!