Is there any way for Service Desk to generate kb links that do not require a customer log in?

[Catherine Chong]

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+Due

Ideal shareable link URL:
https://kb.brokerlinksoftware.com:8444/pages/viewpage.action?pageId=2326784

Additional info:
Our Service Desk deployment is on https://support.brokerlinksoftware.com:8443
Our 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?

[Andy Heinzer]

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

1. put it in the last position so Crowd comes first for those users and data
2. make it Read Only
3. Set Update group memberships when logging in to Never or for newly added users only

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. 

[Liana Aghasyan]

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:

• Customer reports an issue via the support email to us
• The support email is linked to a Jira Service Desk. A new support incident is created in Jira SD.
• The support agent looks for a KB article in Confluence via the support incident instance and replies to the customer with a link on how to resolve the issue
  • Expected Result: the customer that reported the issue via email can view the KB article sent via Service Desk reply without creating a username/password. 
  •  Current Behavior: customer has to create a username/password to view the KB article

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. 

[Andy Heinzer]

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).

[Liana Aghasyan]

Hi Andrew, here are our settings:

Jira Application Links:

Confluence Application Links:

[Andy Heinzer]

Hi Liana,

In your case I think the application link looks fine.  But given the steps you have described, the end user is going to need to have a login for both Jira Service Desk (first) and in this case Confluence to make this work.  If users are able to create a service desk request via an email, they already have a login for Jira Service Desk.  Maybe they are unaware of what that is, but you can't create issues in Jira without it.  

The first time a user emails a Jira Service Desk, if they don't already have an account, and Service Desk allows them to create request, those users get an activation email as well, where they have to go to the Jira site and set a password for their account.

I understand you are seeking a way to not have them login at all, but the way this integration is designed, there is an expectation that the user would have an account on both applications.

Please see the KB: Guide to link Knowledge Base to JIRA Service Desk for unlicensed user It better explains the background on why this is, and how you can set this up so that these service desk customer roles don't actually consume a license seat in Confluence.  You can actually do this for your customers so that they don't have to create their own credentials in Confluence again.   There is a related bug ticket for this similar scenario in https://jira.atlassian.com/browse/JSDSERVER-4233 That ticket has a work-around here that I think would be helpful for you to apply in your environment:

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

1. put it in the last position so Crowd comes first for those users and data
2. make it Read Only
3. Set Update group memberships when logging in to Never or for newly added users only

By following these steps, you can be sure that your Service Desk users already have login credentials in Confluence that are the same as Jira.

There is no way that I am currently aware of to force Jira Service Desk to use the alternate URL.