Our knowledge base is open to Anonymous users and everyone can view articles fine without having to log in. But when using Service Desk to share a knowledge base article as a comment, the link generated, when clicked, requires our clients to log in before they can view the article. Current link generated by Jira Service Desk:https://support.brokerlinksoftware.com:8443/servicedesk/customer/kb/view/2326784?applicationId=c343b113-bd36-39d3-ad9b-d3ec1fde09b6&spaceKey=AKB&title=Wrong+payment+amount+for+Debit%2FCredit+%28Deb%2FCred%29+-+usually+double+or+quadruple+of+the+Amount+DueIdeal shareable link URL:https://kb.brokerlinksoftware.com:8444/pages/viewpage.action?pageId=2326784Additional info:Our Service Desk deployment is on https://support.brokerlinksoftware.com:8443Our Confluence deployment is on https://kb.brokerlinksoftware.com:8444
Is there a way to get Jira Service Desk to generate a knowledge base article link that is open to Anonymous users?
Hi Catherine,
This is a pretty common complaint when integrating Service Desk with a Confluence Knowledge base. The way this integration is setup is using some form of OAuth. This makes an assumption that your users actually have user accounts on both applications (Jira and Confluence).
In this case, it's not the link being generated that requires a login. In fact, the kb link you posted can still be viewed without a login. The problem here is that the oauth integration believes both applications will be using a shared userbase, and in turn when the logged in user in Jira clicks this link, they are getting a login failure on Confluence, which I believe is then triggering a prompt to login before seeing the page.
I'd recommend checking out this KB: Guide to link Knowledge Base to JIRA Service Desk for unlicensed user
It explains in more detail how this feature is intended to be used, and the expectation that both applications would have the same user base. That is actually what I would recommend doing here. You don't need to license all these Jira Service Desk customers inside of Confluence to make this work. There is a related bug on this problem in https://jira.atlassian.com/browse/JSDSERVER-4233
One of the work-around on that bug ticket explains how you can add a Jira User directory inside confluence as a means to get all of these users in Confluence quickly:
Set up in Confluence a Jira User Directory. This pulls in all the users (licensed and unlicensed), but since they don't belong to the groups in Confluence with Can Use permissions, then they don't count towards the Confluence license. When you set up the User Directory put it in the last position so Crowd comes first for those users and data make it Read Only Set Update group memberships when logging in to Never or for newly added users only
Set up in Confluence a Jira User Directory. This pulls in all the users (licensed and unlicensed), but since they don't belong to the groups in Confluence with Can Use permissions, then they don't count towards the Confluence license. When you set up the User Directory
Just having a shared user base between these two applications will certainly help with making this integration work more seamlessly to your end users. This way OAuth with impersonation can be used for this application link and in turn the users can click these KB links without the need to enter Confluence login credentials to view the KB. At the same time, if they share the link to this KB to other users that don't have a login session going on either site, they too can still view this article if the space permissions allow it anonymously.
In short the problem tends to be that your Jira Service Desk customers are not really anonymous when trying to view Confluence pages via Service Desk links. Even though you might have anonymous access open there, there is an expectation here that clicking on a link from Service Desk is going to give that user some level of session data that the other program is trying to use.
Hi Andrew, thanks for your prompt reply. I am working together with Catherine on this issue. Here to reiterate the use case we are trying to achieve:
I checked our current setup and we do share the users between Jira and Confluence. Here is our setup:
And here is an example of a user who reported an issue via email:
In Confluence:
The same user in Jira:
Confluence Global Permissions:
From what I can see, our setup is as you described above, however users who do not have a login to Jira Service Desk cannot view the KB articles in Confluence with the link sent via Jira Service Desk (https://support.brokerlinksoftware.com:8443/servicedesk/customer/kb/view/2326784?applicationId=c343b113-bd36-39d3-ad9b-d3ec1fde09b6&spaceKey=AKB&title=Wrong+payment+amount+for+Debit%2FCredit+%28Deb%2FCred%29+-+usually+double+or+quadruple+of+the+Amount+Due). Is there something that we are missing in our setup? Your help is appreciated.
Can you tell me more about your application link in use here? For this kind of setup I believe that Service Desk is going to prefer to use the "OAuth with impersonation" option.
It's possible these users would still see a login prompt in Confluence if you were using a different method, such as just "OAuth" (without impersonation).
Hi Andrew, here are our settings:
Jira Application Links:
Confluence Application Links:
It looks like you're new here. Sign in or register to get started.
