If it is reproducible in the other environments I would say Yes go to HI.  I tried searching to see if there where any known issues but I have now found anything for Kingston.  I could be a bug that was introduced by the patch that they do not know about yet.

Hi Brian,

 

Yes it is same in both Dev and Uat. I have gone for HI incident. Meanwhile workaround has been provided by @Suraj Chauhan in this thread. I will fix it according to the work around but the HI incident is for the client satisfaction.

Thanks a lot for your quick guidance.

Arnab

wadeaux
Tera Contributor

Did you get a patch recently? This happened to us last week after Kingston patch 12. It was affecting service portal as well as platform searches. We opened a case on HI but after a few days it magically started working again with no fix. I believe it was some kind of caching issue. We are getting the patch for prod next weekend and I expect we will see it again.

Yes exactly patch12 has introduced this issue.However it didn't get fixed automatically as the case with you. Poor guy myself may be. But thanks for your information and participation.

 

Arnab

User179407
Mega Guru

Hi

We upgraded to Kingston Patch 11 and faced this issue, see below the reply from HI support.

This is a known issue reported in PRB1244576. There is a workaround for this by modifying the data fetch script on the search source record:
http://instancename.service-now.com/nav_to.do?uri=sp_search_source.do?sys_id=c96eb1686721220023c82e0...

Please edit line 16 of the Data Fetch Script to pass in the catalog value which is set earlier in the script.

Current code:
if (!catalog_item.canViewOnSearch() || !catalog_item.getFirstAccessibleCategoryForSearch()) {

Workaround Code.
if (!catalog_item.canViewOnSearch() || !catalog_item.getFirstAccessibleCategoryForSearch(portalValue)) {

Hope this helps.

 

Suraj Chauhan

View solution in original post