We are trying to enable the Knowledge Base of Jira Service Management for Virtual Agent. During this step, we understood that we need to lower the accessibility of Space to the "All logged-in users" level from "Only Confluence users."https://support.atlassian.com/jira-service-management-cloud/docs/activate-or-deactivate-ai-answers-in-the-virtual-agent/#Activate-or-deactivate-Atlassian-Intelligence-answers
However, we realized an issue while attempting this step.(https://ggnetwork.atlassian.net/wiki/spaces/RCQ/settings/permissions/anonymous)This operation requires allowing global anonymous connections. (https://ggnetwork.atlassian.net/wiki/admin/permissions/global?tab=anonymous)
Since we use Jira and Confluence as our enterprise workflow management systems, we cannot turn off global anonymous access restrictions, a very secure option for simple PoC testing.We want to use a temporary new space for PoC. Is there a way to supply the Confluence Page as a knowledge base to JSM without turning off the global security device?
Hello @Jack Lee
I also looked for information on this issue, but found nothing(
Welcome to the Atlassian Community!
Anonymous access is done in two layers - global and space.
The global flag does not allow anonymous access to anything. If you turn it on, no-one will see any more than they could see before.
You enable anonymous access in each space individually. But you can not enable it if the global flag is "no anonymous access".
And even if you turn the global on, add anonymous access to a space, and then turn off the global, the space will stop being anonymously accessible. (It keeps the setting though, so it you re-enable the global, it'll become accessible again)
Hi Nic,
Your explanation matches my understanding. I'm just wondering if I can make a case to circumvent the constraints or make an exception case.In the current constraints, enterprise organizations can never enable the Virtual Agent's Knowledge Base function.
Thanks for sharing the case, Viktoryia. 😥
Hi Jack,
There could be a case to look at, but I will admit that I am very uncertain of it. Not because I think you might be wrong, but because I am not sure I understand.
Enabling anonymous access globally in Confluence does nothing other than enable the space owners to allow anonymous access to their space.
I do not understand why this structure is a problem. I am certain I am missing something.
If you could help me understand, then the first question I would ask is why an enterprise cannot enable a Virtual Agent's Knowledge-base function. What is wrong with that?
The virtual agent requires the Knowledge Base Space to be open to "All logged-in users" or broader. I am guessing this is because the client authority of Slack or Virtual Agent should not have an equal or higher level than the confluence user.
I referenced the following part of the guide.
Before you begin, make sure:you have a knowledge base space linked to your project your linked knowledge base space is set to All logged-in users under Who can view your organization admin has turned on Atlassian Intelligence
Before you begin, make sure:
We created a space dedicated to the knowledge base for the agent and changed access levels of this space to anonymous reading, but the Virtual Agent is still not using knowledge base contents. Actually, there are no warnings or errors. Since the Virtual Agent keeps asking the same questions to determine intent, we assume it cannot access the knowledge base space due to the global anonymity setting.
It looks like you're new here. Sign in or register to get started.
