Article not found when in multiple categories - InstantKB

InstantKB Problem
Hello - we had an interesting case earlier this week that I am sharing to see if anyone else has seen it and if the causes are known.

We created an article on how to add articles to the KB. The person who created the article put it into one primary category and 6 secondary categories. The article was made accessible to Admins and also to four different member groups that correspond to the support staff for 4 different product lines. However, of the secondary categories assigned some were only visible to support staff for 1 or 2 of the four product lines.

The article turned up in searches conducted by those in the Admin group, but was invisible to anyone in the support staff member groups.

From running queries I confirmed that all the categories and member groups checked off in the UI were in the article or the related tables.

I then edited the article so it was only in one category - in this case it was OK to do so and still give staff access. At this point it appeared in the searches for staff.

I conclude that putting the article in multiple categories caused the problem, but I am concerned I don't know how to avoid it in the future - for example, if we have a windows related issue that affects several product lines, I want to be able to put the article in several categories without the chance that it will disappear from some searches by users or support staff.
Has anyone seen this issue and can they give me a 'rule of thumb' for what to avoid when assigning an article to more than one category? Any help is great!
InstantKB Problem

This bug has been there for quite a while.  I'm running quite an old version (2.0) and have it myself.

The only work around  I found was to put the primary category as the lease secure of the categories.  Though this only works if you have a basic hierarchy structure.

All i have is Every --> All Staff --> All admins.



Yep, I just reproduced this and also I can see in the source exactly where it's happening.

in 2.0.6, source file business\search.vb

' ensure we only select articles within categories member has access to 
sb.Append("EXISTS (SELECT RoleID FROM InstantKB_CategoryRoles AS cr WHERE ")
sb.Append("cr.CategoryID = a.ArticleCategoryID AND cr.RoleID IN (")

You would need to check for something like cr.CategoryID in (select categoryid from instantkb_articlecategories where articleid=a.articleid)

(I'm pretty sure that the primary categoryid is always also in the articlecategories table).

Funnily enough nobody here has complained yet but we are still using a database upgraded from ikb1.3 and permissions are generally applied to folders, not individual articles.

If I get some time I will have a play with this.


Thanks much for the responses.  I appreciate it.

This bug does present some challenges to us somewhat for staff and more so for our clients. 

We have hierarchies for each of our product lines and have set up our system so that clients in one product line don't see the categories and articles for the other.  

This looks like it could be a real problem if we want to make an article in one product line accessible to users in another product line because it is a cross product issue, eg a Windows issue.  

I suppose one approach is to create a root level category for cross product issues and let all client member groups have access to the category, then limit access to individual articles based on products involved. We could also look at creating a cross product category within each product line and carve out an exception so it is visible to other products users also.  Neither of these approaches are great but the second one is at least less visible since it is down a level in the category tree and not immediately visible in a category view.

Do you have any other suggestions?


I can confirm that my suggested SQL change doesn't obviously break anything and appears to return the correct results. I haven't tested it fully but it found one or two things that were being missed before.

It might take longer to run, since there's another subquery involved, but there's already a ton of subqueries in these searches anyway.

If you can't or don't want to make this change, I'd actually go for the single new category for all cross-product issues. It's more maintainable and you can always give it a friendly name that will sound impressive.

9 Years Ago by Charles

Existing Account
Email Address:


Social Logins

Select a Forum....

InstantASP Forums