Global Search seems to ignore KM rules when an exact match is found on number

jay_carrick
Giga Contributor

When searching using the global search (top right of UI, Eureka), the search ignores all my rules for KM articles if the exact article number is entered.   The global search ignores the rules for if the article is Retired, passed the valid-to date, role matching, not active, blank published date, etc..   This ONLY occurs when an EXACT match is found with the article number.   This behavior does not occur if you are within KM and the KM view/search.     Is there something missing that is allowing this to occur in the global search?

 

Example:

Article KB0099445 is retired.

 

In global search I enter - KB0099445, it will be returned.     If I only enter 99445 in global search, an exact match is not found and all the rules apply and the article is not returned.

 

In KM search I enter - KB0099445 and it will not be returned because the rules are applied.

 

Any suggestions?

1 ACCEPTED SOLUTION

jay_carrick
Giga Contributor

From ServiceNow


Knowledge management was designed to have kb_knowledge records set to "Retired" when their "Valid to" date had expired. Once they are set to "Retired" they can either be deleted or archived else where.



If you would prefer to keep records that are retired there are several options you can use that are built into the platform to prevent access.


--You can create an ACL condition for "is not retired" and the role would be set to ITIL or whichever role you would like to prevent access.--You can create a before query business rule that adds an additional condition to any query against kb_knowledge if a condition is met


What our developers did was:


Create a script that avoids the access to retired articles to all user that does not have 'knowledge_admin' role.     This way a person that is a knowledge admin can still always find a retired article in regular search (or using the normal edit list).


View solution in original post

8 REPLIES 8

Yes the conditions are all set and work great within KM search.     They even work correctly when there is not an exact match from the global search.     It is only when an EXACT match is found on the number that the issue occurs.


domaners
Kilo Guru

Hi Jay. This does sound like a bug, and should be reported is it may affect many other customers. As a workaroud though, have you tried using an Access Control to restrict read access for published articles?


jay_carrick
Giga Contributor

From ServiceNow


Knowledge management was designed to have kb_knowledge records set to "Retired" when their "Valid to" date had expired. Once they are set to "Retired" they can either be deleted or archived else where.



If you would prefer to keep records that are retired there are several options you can use that are built into the platform to prevent access.


--You can create an ACL condition for "is not retired" and the role would be set to ITIL or whichever role you would like to prevent access.--You can create a before query business rule that adds an additional condition to any query against kb_knowledge if a condition is met


What our developers did was:


Create a script that avoids the access to retired articles to all user that does not have 'knowledge_admin' role.     This way a person that is a knowledge admin can still always find a retired article in regular search (or using the normal edit list).


atherakhtar
ServiceNow Employee
ServiceNow Employee


When performing a global search on any draft knowledge wany draft knowledge will appear and this is the expected results since both "task" and "kb_knowledge" tables are being searched and any results will be returned no matter how the permissions are being set in the knowledge search. 

I have written a business rule which you can modify based on your needs and achieve the desired results. 

In the business rule only the user with admin role would be able to see the records in draft state when searched in global search for the other users it wont show up.

Please mark this as helpful to help other on community.

 

Cheers !!

Ather