Can we restrict Anonymous Access to viewing only some articles in the Knowledge Base?

We have Clients who administer our product, and they have Customers who use our product.

We need to provide restricted, Client-Customer access to Knowledge Base articles (Client-Customers see how-to articles but not administration articles) and we need to provide un-restricted access to all articles (our Clients see the restricted how-to and un-restricted administration articles).

We don't need to restrict or hide parts of articles (although we could handle this that way), only whole articles.

In Confluence I think we would use the Unlicensed Access Global Permission for Clients (Administrators) and Annonymnous Access Global Permission for Customers (Users).

In Service Desk I think we can use Portal Only access for Clients (Administrators) to match to Unlicensed Access in Confluence (all articles). Client-Customers (users) generally don't accees Service Desk.

The Knowledge Base space would be linked to Service Desk for access by Portal Only users and the Knowledge Base space would accessable outside Service Desk for Client-Customers (users).

Our issue is that, other than Annonymous Access (public), the Confluence Space Permissions do not include an Unlicensed Access level, only individual and group. The View permission seems the same for both Users and Annonymous; they both see all the articles. So there seems no way to restrict View access by Annonymous to only some articles.

In another solutiuon, tagged articles in the Knowledge Base are only viewable by similarly-tagged Service Desk Organisations and Customers, with the public view of the Knowledge Base restricted to only un-tagged articles. This works for us.

In Confluence we can label articles, so that covers a core requirement.

What we need is the Service Desk Organisation to be labelled to provide access to similarly-labelled articles in the Knowldege Base space (as well as to all un-labelled articles). Linking the Service Desk Customer to labelled articles as well would be even better (then we can differentiate between our various Clients as well).

We want to move to Service Desk, but would also need to move the Knowledge Base to Confluence a well, and this issue will stop both those things happening.

1 answer

This widget could not be displayed.

Hello Paul,

In order to accomplish this from within Confluence, you would need to

  1. Turn on Anonymous "Can Use" access in your Global Confluence permissions.
  2. You would then need to go into each space where you want none of the pages to be accessed by Anonymous users and edit Space Permissions, removing anonymous access.
  3. In the space where you do want them to access a few of the articles, you will need to add page restrictions to the pages you do not want anonymous users to access. You can give the view and edit permissions to the confluence users group on the pages. So every page you do not want anonymous to access would need the restriction added to it.

Please also be aware that if a user is a JIRA or Service Desk Customer, then they are not considered anonymous, and would need to be logged out in order to see any pages that are set up for anonymous access.

Regarding the Service Desk access to a Knowledge Base in Confluence, we do have a feature request for what I believe you require:

Please review that and if it meets your requirements you can provide a vote on it to help show our team the interest for this feature.

Let us know if you have any questions about any of this!

Kind Regards,
Shannon

Thanks, Shannon.

We can't cope with needing a license in Confluence for each client adimistrator (there will be too many), so they need to be anonymous/unlicensed as well (Portal Only needs to link to some Anonymous articles).

We need a way to label Confluence articles so that they are for either a "User" or an "Adminstrator".

  • Anonymous can see "User" articles on a topic
  • Portal-Only users in an Organisation tagged as our client can see both"User" and "Adminstrator" articles on the topic, from the same search. If an Administror searches for "Entry" they will see what the "User" would see a search for '"Entry", plus any "Adminstrator" articles on the topic.

What currently works for us is:

  • Knowledge Base
    • Articles are grouped in separate sections for Admins (manage it) and for Users (use it).
    • The Admin sections are all tagged for access by Portal-Only users with a tag or tags, e.g. "client", "Client A".
  • Service Desk
    • Portal-Only organisations can be tagged as "client". Portal-Only users in a tagged organisation can then see "client" articles.
    • Portal-Only users can have an additional tag for thier particular client organanisation (e.g. "Client A"). These users can see all "client" articles via their "client" tag, but also the articles only tagged "Client A" (e.g. release notes are for all "client" access, but release notes for specific features are tagged "Client A" and are accessible only to users tagged "Client A".

All the articles are currently in the same "space".

I am not sure that the feature request quite fits. I'd need to read the requirement for it, since that is not clear enough in the ticket (to me).

Does that help clarify the issue?

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted yesterday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

71 views 1 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you