Skip to main content

Hey we've made our community hybrid in visibility; most community categories are only available to registered users.

We would like to hide federated search results from non-logged in users as it is mostly documentation for staff (who are our registered users). Is there a way to do this?

Following along to see what the answer is as i’m also interested in this!


I don’t believe it’s possible. There’s nothing in the federated search API for setting permissions on the content, and there’s nothing beyond the API for controlling the settings. 

This would be a great idea to add, as I think there’d be a lot of use cases.


Yeah, i was thinking that in the meantime, I could look into the InsidedData objects and target the results by class or something.


@jvdc Wow that is an interesting thought.  To create an automation that fires the federated search API depending on role found in the inSidedData object.  I’ve never heard of someone attempting that, and have no idea if it’s feasible.  Let us know if you can make it work!  :)


So I have managed with some extensive scripts.

This will do for now, but it would be great if there was an admin feature for this, so I've created it as an idea too:

 

As there were not specific tags or classes for federate search results, I basically used the external link icon that shows up next to a federated search result to identify them.

Additionally, I had to make the script listen for changes and keep applying the hiding function, because the search results list in an infinite scroll mode where new results show up as we scroll down.

Finally I also hid them from the quick results showing below the search-bar when we're on main pages. There, there was no identifying element whether or not a result was federated search, so I had to target it by href.

The only thing it doesn't do is correcting the search-count. So we might have zero results showing up because we're hiding federated search but the search count might be larger than zero.

Replace xxxxxxxxxx with your own data :-)

if (inSidedData.user.role === 'roles.guest') {
$(document).ready(function () {
// Hide them from results page(articles with .icon-externalLinkV2)
function hideArticles() {
$('.icon-externalLinkV2').closest('article').css('display', 'none');
}
hideArticles();

const articleObserver = new MutationObserver(mutations => {
mutations.forEach(mutation => {
mutation.addedNodes.forEach(node => {
if (!(node instanceof HTMLElement)) return;
if ($(node).is('.icon-externalLinkV2')) {
$(node).closest('article').css('display', 'none');
}
$(node).find('.icon-externalLinkV2').closest('article').css('display', 'none');
});
});
});
articleObserver.observe(document.body, { childList: true, subtree: true });

// Hide the federated search results filter button
$('button[tab-id="xxxxxxxxxx"]').closest('li').css('display', 'none');

// Hide them from the quick search result (items linking to xxxxxxxxxx)
function hideAlgoliaItems(container) {
$(container)
.find('li.algolia-search-result a.algolia-hit-item[href*="xxxxxxxxxx"]')
.closest('li.algolia-search-result')
.css('display', 'none');
}
hideAlgoliaItems(document);

const algoliaObserver = new MutationObserver(mutations => {
mutations.forEach(mutation => {
mutation.addedNodes.forEach(node => {
if (!(node instanceof HTMLElement)) return;
hideAlgoliaItems(node);
});
});
});
algoliaObserver.observe(document.body, { childList: true, subtree: true });
});
}

 


All I can say is WOW - awesome work :)