Confluence permissions for service desk kbd

[Pedro Perejón Fernández]

We have Jira-ServiceDesk and also Confluence, which is used to get knowledge database articles. The fact is that to have the autocomplete answers running we must:

• Link service desk to a confluence space,
• The space in confluence has to be public,
• Anonymous users have to be able to browse confluence (instance permission).

This is the only way we've found to have this working, but this also means, that our knowledge base is publicly available on the internet. Is this true? Is this the only way?

Thanks in advance!

[Elisa [Atlassian] · Accepted solution]

Hi Pedro, 

Yes, that configuration is correct. Other thing you could do to restrict your Confluence space is add your customers as Confluence users and grant them permissions to view/access the space. Unfortunately this would cost you confluence-users permissions which would probably modify your user tier (increasing the costs of your license).

If you'd like this to be handled in a different way, if you have suggestions on how to better implement this feature, we would be glad to hear it.  You can post your suggestion here or send it directly to our developers via the feedback channel on JIRA and JIRA Service Desk. 

[Ruth Cheesley]

This is a big issue for us as well.  We've embraced Service Desk and we love the integration with Confluence and Jira, but the huge issue for us is we have many clients, with different spaces on Confluence.

We simply cannot make those spaces available to the public.  We use our spaces in Confluence for meeting notes, project update reports, retrospectives and so forth which cannot be made available in the public domain.

What I would suggest is a 'customers' ACL similar to what you have in Service Desk.  Customers on a service desk are given read-only access to the resources that are linked in the Service Desk settings, plus any public spaces that might be available.

Ruth

[Pedro Perejón Fernández]

Hi and thank you again.

Wouldn't it be easier to put a robots.txt on the root of the domain like this:

User-agent: *
Disallow: /

I mean, instead of asking Atlassian to upload the google site ownership file to the root of the domain, just upload that robots file, and that's all. That way, we don't have to check the property with Google, or any other search bots existing or future (bing, yahoo, etc...).

What do you think? Is it possible? or should we begin creating webmaster accounts in the main search engines?

Thanks,
Pedro.

[Elisa [Atlassian]]

Yup, sure thing! :) Unfortunately that won't be possible. Cloud applications are very restrict about editing source files. You will need to create the webmaster's accounts. :/

[Elisa [Atlassian]]

Hi Pedro,

Thanks for the feedback. I'll be showing this to our Product Advocates team. :)

About your question.. Yes, by default both JIRA and Confluence when anonymous access is enabled will be exposed to any search engine (specially Google).

Though, you can disable this feature. First you need to use Google's URL Remover Tool. This first requires you to verify that it's your site via Google's Webmaster Tools by uploading a specially-crafted HTML file to the root of the domain.

After this verification, raise a ticket on Atlassian Support (support.atlassian.com under Cloud) and send us the file Google generated for you and we will proceed with the maintenance.

Hope this helps! 

[Pedro Perejón Fernández]

Thanks a lot Elisa, for your fast answer.

Anyway, I think this should be adviced in your commercial info. Now with over 200 potential service desk clients that don't need confluence for other matters, we can't afford the costs of confluence licenses.

If this is the only way, ok, we'll make the space public, but now there is another question, more about confluence, but that affect this kind of service desk support spaces ¿are the spaces of confluence (oncloud) exposed to search engines? 

I know that with ondemand versions I can configure my own robots.txt to manage this, but what happens with spaces oncloud?

Thanks again!