Retired Knowledge articles in Global search

[harishdasari]

Hi,

can anyone help me, how can I make the retired knowledge articles not to be visible in Global search.

Actually service desk users are able to view retired knowledge articles by entering the number in global search.

can anyone please provide me the solution.

I have tried creating READ ACL on kb_knowledge table, but no use.

Thank you.

[willow1]

I wonder if this is somewhat related to my pending question: Should links to KB articles that have been retired still work?

[antin_s]

Hi Harish, and All

Global Search works based on Zing search for which the persistence of the search terms is done while updating/inserting the KB itself.   That's the reason Global Search is pulling the retired KBs though the Search Groups has filtered out 'retired' articles. Because the persistence of the search terms would have been done when the KB was active, and surely before you (just) modified the Search Group. I agree there should be a mechanism to remove the persistence for the records which don't match with the Search Group Filter conditions.

Fix:

Create a 'Before Query' business Rule, and use the result of current.getEncodedQuery() to differentiate between Global Search and other list/form views. The Global Search comes with the encoded query as   '123TEXTQUERY321=xxxxxxxxx'   (where xxxxxxxxx is the search term)

This would help avoiding showing the retired KBs to be shown in search result if the search wasn't done with the KB/Incident number. If the search is done with the KB/Incident number, the encoded query is same as a form view (sys_id=9c573169c611228700193229fff72400) as the record is directly queried. So this will show up. But it's up to if you want to block that too for certain users.

Thanks

Antin

[Dave Smith1]

I think the point is that this is a fix being applied to a process broken internally.

I understand your explanation of why it happens - but don't let that distract from the fact it actually happens and it should not.

I've reported this as incorrect on the documentation site, as well as raised a Hi issue - I've not seen any response from saruppaul or coryseering as yet.

[coryseering]

Hi Dave and everyone else,

Goran is correct. Exact Match searching goes down a different path than keyword search. I tested on a Eureka instance, and the behavior with regards to Exact Match number searching works the same way there as it does in Jakarta.

I rewrote the Exact Match search in Jakarta, and I was pretty sure I had preserved old behavior, while allowing for a more expansive search matching experience (you can exact-match any type of record, if it has an auto-number field and Number Maintenance record). The behavior seen here appears to be the legacy behavior that is expected.

It's quite justified to say that the behavior should be different. If you believe retired articles should not appear in exact-match searches, please open an Incident in Hi. I think this qualifies as an enhancement request, but I also don't own this product, I just worked on it. An Incident opened by a customer negatively affected by the way that this works can result in a new Story or a new Problem, to change the behavior. I can't unilaterally change it, and since it's working the way I expect it to I can't just open a Problem for it either.

Remember that the more people who get behind a push to change something, the more weight it carries- which means we can prioritize it for a quicker release, and possibly even a backport for those Problems which merit one.

Thanks

Cory

[Dave Smith1]

Cory Seering wrote:

It's quite justified to say that the behavior should be different. If you believe retired articles should not appear in exact-match searches, please open an Incident in Hi. 

I believe the behaviour should be as documented: Retire a knowledge article says Retired knowledge articles are no longer available for users to view.

I recognise, in this context, that knowledge workers aren't classified as ordinary users - librarians removing books of the shelf doesn't mean those books become invisible to them, but are concealed from public gaze.

Cory Seering wrote:

I also don't own this product, I just worked on it. 

I think we're all in agreement that you can't be held accountable for correctly building a flawed design.   But your insight into the underlying algorithm is invaluable, so thank you greatly for revealing that information.

Cory Seering wrote:
Remember that the more people who get behind a push to change something, the more weight it carries- which means we can prioritize it for a quicker release, and possibly even a backport for those Problems which merit one.

This is probably the desired course of action: the more calls for change, the greater the weighting.   However, at present there's definitely a discrepancy between the official documentation and exhibited behaviour - one needs to be changed so they're both singing off the same songsheet. In my opinion, that's not an enhancement request - it's a correction.