How to hide non-published KB articles from searches, except members of a particular AD group?

Tom_Hendricks

Some explanation of why I am asking this... I need all my analysts to be able to create KB articles, but did not want to give them "knowledge manager" privileges.  I adapted a version the code for Asset Management roles to selectively hide fields (e.g. Status, so only KB mgrs. can publish) and only allow edits to one's own articles if they are not a KB manager.  It works great!  However...

Now all my analysts can see Draft articles in their searches.  I had to put my analysts group in the KB Managers setting, and then selectively disable KB manager functions except when the user is a member of a certain AD group that is also a member of the analysts group.  So this is an element of the KB Managers role that I am not seeing how to hide.

Any thoughts on how to either reverse the logic of my solution to prevent this or to hide the unpublished articles?

Nicholas_Velich

It's not the best possible solution, but you could get closer by doing a timeout:

$(document).on('change', function() { 

       setTimeout(function(){ 

              console.log("Hiding draft KBs!")

              $("div.article-result:contains('[Draft]')").hide(); 

       }, 750);

});

The better way to go about it would be to create a mutation observer which monitors the presence of those objects and hides them when they eventually appear. There are a few examples of mutation observers on the Downloads page.

One other important note is that using the $(document) selector here is too open-ended which could lead to some unexpected behavior. The above code as-is would execute on a change of any element on every page of the Portal, and we only want it running on the KB Search Page against a specific element. To see this, put that code in your custom.js file, and you can see it execute (via the console log message) on various other pages of the Portal.

You can make your base selector more specific by using JQuery with more specific CSS selectors, using the information here: https://www.w3schools.com/cssref/css_selectors.asp

Lastly, we can verify that whatever code we end up with only runs on a certain page by wrapping it in an "if-statement" that checks the URL. For example:  

if(url.indexOf("/View/0aef4765-0efa-4a65-84c1-324b09231223") != -1){  ... }

Thanks,
Nick

Tom_Hendricks

What I have been attempting so far:

$(document).on('change', function() { $("div.article-result:contains('[Draft]')").hide(); });

The issue is that the event fires after the search is submitted, but before the new results are rendered on the page.

Nicholas_Velich

It's not the best possible solution, but you could get closer by doing a timeout:

$(document).on('change', function() { 

       setTimeout(function(){ 

              console.log("Hiding draft KBs!")

              $("div.article-result:contains('[Draft]')").hide(); 

       }, 750);

});

The better way to go about it would be to create a mutation observer which monitors the presence of those objects and hides them when they eventually appear. There are a few examples of mutation observers on the Downloads page.

One other important note is that using the $(document) selector here is too open-ended which could lead to some unexpected behavior. The above code as-is would execute on a change of any element on every page of the Portal, and we only want it running on the KB Search Page against a specific element. To see this, put that code in your custom.js file, and you can see it execute (via the console log message) on various other pages of the Portal.

You can make your base selector more specific by using JQuery with more specific CSS selectors, using the information here: https://www.w3schools.com/cssref/css_selectors.asp

Lastly, we can verify that whatever code we end up with only runs on a certain page by wrapping it in an "if-statement" that checks the URL. For example:  

if(url.indexOf("/View/0aef4765-0efa-4a65-84c1-324b09231223") != -1){  ... }

Thanks,
Nick

Tom_Hendricks

Excellent points.  I have noticed this, while working on other customizations, but never circled back to this one to update it.  For anyone else following along, this is definitely a more solid approach than what I originally wrote.