Hi be913a391036 ,

Crowd is not a requirement to make this feature work.

If the two applications (Jira Service Desk and Confluence) are linked using Oauth with impersonation customers should be able to view knowledge base articles without logging in. 
Steps to link Jira service desk and Confluence remain same - https://confluence.atlassian.com/servicedeskserver/set-up-a-knowledge-base-for-self-service-956713310.html#Setupaknowledgebaseforself-service-trueapplink_confluence.png503.LinkJiraServiceDesktoConfluence 

Thanks,

I'm unclear whether this solution still requires you to set up a central user repository for Jira Service Desk and Confluence (e.g. Crowd https://confluence.atlassian.com/doc/connecting-to-crowd-or-jira-for-user-management-229838465.html ) 

The latest Bug fix article https://community.atlassian.com/t5/Data-Center-articles/February-update-the-latest-bug-fixes-product-improvements-and/ba-p/1293614?utm_source=newsletter-email&utm_medium=email&utm_campaign=bug-fix-february-2020_EML-6275&jobid=104537380&subid=1462552408 says "a Confluence log-in is no longer needed to view knowledge base articles", which makes me think maybe we don't need to have Crowd. These bug fix notes me think maybe we still need Crowd (if confluence is not anonymous) but you now don't need to log in twice.

Does anyone know if Crowd is still required?

We wasted 12 hours trying to resolve this issue, raised two support requests with Atlassian Support, those requests refer to this "bug report".

The fact that Atlassian did not notify us (and many others) that this feature was fixed is AMAZING.

I did not even see this mentioned in the RELEASE NOTES which is where it should be listed prominently.

And yes, the Jira Service Desk release notes are completely useless.

Yes, good work on fixing this bug. Bit of a massive fail on communicating the fix.

Hi Kunal, thanks a lot for telling this.

Why is there no way of knowing this from the ticket ?

No link to an existing Confluence Server ticket, nothing mentioned in the description...

Work half done here, tickets shouldn't be closed like this

The fix for this problem is released with Jira service desk 4.6.0 and confluence 7.1

To resolve this issue, please upgrade Jira service desk to version 4.6.0 or higher and Confluence to version 7.1 or higher

Jira Service Desk 4.6.0 was released on 17 December 2019 and Confluence 7.1 was released on 4 November 2019.

Looking for a release date as well. 

Thanks, 

Cameron

Hi,

Could we have a release date please ?

Best regards
David

Hi Atlassian,

me and my customers are waiting for it, I think waiting for 4 years should be more than enough. Please let us know the release date.

Thanks
Heiko

Is there an anticipated release date for Service Desk 4.6.0? We have a customer who would like to take advantage of this feature, so we'd like to provide them a rough timeline. 

After Jira Service Desk version 4.6.0 and Confluence version 7.1 this issue should be resolved.

Can Atlassian communicate externally if it is going to be implemented?  and I'm curious why it isn't filed as a bug but as a suggestion? This is clearly the system behaving wrongly.  

Agree with @Anthony Martin - you can do better than "gathering feedback" after 3 1/2 Years ....

It is really inconvenient and should not be needed as additional step for customers. 

Anonymous access is not an option for many organizations because Service Desk Customers having access does not mean automatically it is for public availability.

I am with Adam here. Horrible UX. The suggested solution in JSDSERVER-3751 doesn't make it much better. For a user without any further access to that Confluence instance it is not reasonable to login twice.

One of our Customers actually noted this as a negative point in the Service Desk evaluation process.   

This is a nightmare. How the heck you want us to explain to our customers that they have to login twice? .. Nobody who is sane will use that product and leaves the page and write an e-mail or call the hotline rather than to find solution themselves. This is true Atlassian experience it could not have been more user unfriendly, could it?

Come on @Atlassian / @Admin - do you not think you can do better than "gathering feedback" after 3 1/2 Years?

Not only is the original flaw / fault / feature request an incredibly poor customer experience for anyone using service desk. Your own lack of movement on this issue is a massive disappointment and clear failure of customer service.

Please address these logon issues.

We use one of the SSO plugins, and are still unable to bypass this issue, which in effect means the knowledgebase is useless for us.

There is a feature request, which adresses that:

https://jira.atlassian.com/browse/JSDSERVER-3751

This is a very strange user experience.  I don't understand why the login process opens a new browser tab.  I believe that if you need to login, at least keep it in the iframe that shows the confluence article.

As you are gathering interest, mine you got, and not a positive one.

Just moved from cloud to on-premise and this issue was a very negative surprise. And seeing that this major drawback exists for so long without being addressed is the second very negative surprise.

I have a workaround for this which met my needs sufficiently, but it is not ideal.

Under Confluence Global Permissions >  Anonymous Access > Use Confluence
I set Anonymous "Can use" **

Then, under Space Tools > Permissions for the Confluence Knowledge Base Space I have tied to Jira Service Desk, I set Anonymous > View All.

Effectively making that info public but read only for anyone in just that Space. This is fine for my use case, and it makes the login prompt issue go away. I can still restrict certain articles to be only viewable by jira-servicedesk-users or confluence-users based on the individual Page Restrictions function.

Just noting that this KB article - Knowledge base settings and permissions was very recently updated to include this statement:

Login process

If you aren't using SSO or something that passes login information between instances, then users will need to log in to Confluence using their Jira Service Desk credentials to view articles.

So at least the lack of integration when using "Atlassian OAuth with impersonation" has now been acknowledged. Unfortunately, JSDSERVER-1551 is still only "gathering interest" despite the obvious requirement for a service desk customer to be able to read a Knowledge Base article from JSD, without having to login again to Confluence. The Confluence login screen provides no instructions as to what login the customer should use or even why they need to login. It's an extremely poor user experience and looking at our own statistics, in 12 months only ONE customer has figured out how to login to Confluence. ONE. That's fairly damning.

"Gathering Interest"? Oh come on. I'm so surprised this is not in your sprint already....!!! 

Absolute far away from customersatisfaction!

We're now reviewing our use of confluence as a knowledgebase as a result of this limitation. The problem is further compounded by the fact that logging in takes the user to the full site experience for the article, and this is not what we want, in any event, we would want the article to remain / to be displayed within the servicedesk portal, as it would if you were already logged in. If we have to log into two places, we might as well leverage a sharepoint portal.

This is really disappointing, please reconsider, this is really needed. Logging twice is a terrible idea. Why do you have to login again, when you are already logged in into the Portal???

Please reopen- would like to vote for this too.

Please reopen, this is a huge issue for our service desk customers. 

We absolutely can't grant anonymous access to Confluence for the sole purpose of accessibility to the knowledge base. Should be authenticating their help desk account and allowing them to view. 

Adding a comment saying that this needs to be reopened because I can't vote on this.

@Atlassian - this really needs to be reviewed. It results in none of our staff using the self service portal and knowledge base, which completely defeats the point of having a knowledge base in the first place! This is a fairly fundamental design limitation.

Seriously? This is an absolute must. This is ridiculous. This has to be working. You can not present your Knowledge Base to the customers like it is now. They won't use it. I would not use it. Would you? I don't think so.

"Won't Fix"?! Are you serious, Atlassian? Granting anonymous access to Confluence is not an option here, either. (Neither is downgrading to earlier software versions where it used to work.) More likely, a migration away from Atlassian products is what's going to happen, if this functionality is not restored quickly.

Agree, this is ridiculous that you can see the article title and some of the body when searching but have to log in to view the article. 

And to close the ticket because "it's not a trivial issue to fix" seems arrogant to your customer requirements.

I don't want to open our knowledgebase to the entire internet community.  They should have to be a support user to see our help desk manuals.

We are having the same issue. Having to log in again totally defeats the purpose of sharing the User Directories. This ticket needs to be reopened!!!!!!

Same issue here. I would like this reopened for resolution. 

Same problem here. Giving the linked knowledge-base space anonymous view access is a workaround until this is addressed. Might not be an option on Cloud (or exposed Server) though depending on what information is housed within.

Same exact problem here. How is this a minor issue?

I have the same problem. I tried reconfiguring all the application links but it does not work at all. Anybody got a solution for this?

How is this a minor issue? We've spent a lot of money on these two products and this is ridiculous. Service desk (JIRA) promotes using a knowledge base (Confluence). Our customers create accounts in JIRA to log the ticket...now I have to have them log in again to access the knowledge base when clearly it says in the software that's not required. See the screenshots: when do we get a refund for false promises?

Hi dconrad,

• From the system design, we would not allow external customers to view entire KB article without logging in. There could be information that are restricted base on security level. And if we use AppLink authorization then we may lose this ability.
• Right now, conie AppLink only allow us to retrieve the list of articles, but not to view the content of each article.

Therefore, I would close this issue with resolution 'work as designed'. However, you might reopen it as a suggestion instead.

cc bbaker

Hi tbuiquang,
The customer wasn't using any SSO solution, as far as I remember.
Nevertheless, the main concern addressed in this issue is the following: Having to authenticate even after setting up a 2LO authentication defeats the purpose of configuring the AppLink with the knowledge base.
Not sure if there are any other customers facing this problem with custom SSO authenticators besides crowd, though.

Hi dconrad
I would like to know more about what SSO application & how do they configure it to work with JIRA & Confluence.
From my investigation locally, I have used Crowd & it works as expected. User after logged into service desk can view KB article without re-login again to Confluence.

In case they do not use any SSO application, then there is no way for us to authenticate against Confluence. Hence, they could not avoid to re-login to view KB article.

Hey tbuiquang. I don't have a lot of experience with SSO authenticators, but I'd assume if a customer had an SSO solution that allows them to log in to Confluence and JIRA/SD at the same time, then yes, that would help in this case.

As to the root cause for this - the reason that the search works but you have to log in to Confluence to view the actual article is that the search runs through Applinks (hence the request works with the Applinks OAuth) but Confluence doesn't provide a way to view a page through Applinks, so the user has to log in to Confluence directly. I recognise that the solution we've provided in letting you log in via the KB viewer dialog isn't ideal, but it's not a trivial issue to fix.

Hi akdominguez Is this issue relates to JSD-1025 which enable SSO access via customer portal login. Hence, the portal customer does not need to login again to Confluence when viewing KB. To enable SSO between JIRA and Confluence, it seems like we need to use one of the system suggested in https://confluence.atlassian.com/display/DEV/Single+Sign-on+Integration+with+JIRA+and+Confluence.
What is your thought in this case?
Cheers

We are affected by this issue also.

Jira - v6.3.9#6339-sha1:46fa261
Service Desk - 2.3.3
Confluence - 5.4.2