In Jira Service Management, can I control what articles the public sees?

[Jim Stemper]

We use Jira Service Management to collect issue reports on our products from employees, beta testers, and VIP/partners. It is also a great way for these parties to find documentation since not all of them are great at using confluence.

Each product's service portal is linked to that product's confluence space, so employees (who do have access to that space) can see all the documentation pertinent to their questions because the space is set to private in the knowledge base permissions:

The problem I am trying to solve is we have some documents (Repair SOP, Troubleshooting guides, Release notes, etc.) that I would like those beta testers and VIP/partner groups to be able to see from that space, but I do not want them to see all of our other documentation.

Is there a way to select which articles an "organization" in Jira service management can see, and limit them only to those articles, without having to create a separate space for those particular articles?

[Matt · Accepted solution]

Create 2 permission groups for this space, naming them whatever makes sense for your use case "restricted-readers", "content-contributors", etc...

"restricted-readers" will need read access to the space, while "content-contributors" will need at least the ability to read/add and delete if that is required.

Any content you don't want VIP/partners to access should have permission restrictions applied and allow only "content-creators" to have access, removing "restricted-readers".

The space would require to have good content organization so you are not applying custom permission restrictions to hundreds of pages.

[Jim Stemper]

@Matt i agree, this would work for sure. Similar to @Elliot Reiter's suggestion above this is a good solution however I am doubtful our organization can achieve this effectively. Im hoping for an admin based solution so I dont have to train the organization on restrictions. I really appreciate these suggestions but I am sure you've found that getting users to do something like this can be difficult and ideally I would manage it with an admin structure. 

[Matt]

Hmm... I don't believe there's much available within the Admin portal for this use case. The only way I could see doing this would be via permissions/restrictions. But if you're comfortable with development against the API you might be able to conjure up something.

With the API method, if your org is comfortable with tags/labels, you could label each page in the space with an appropriate tag and then use the permissions/restrictions API to grant/restrict access based off of the label. Not an easy task but should be possible and your users wouldn't have to get their hands dirty (besides adding a label, but that could also be scripted)

[Jim Stemper]

That is a pretty good solution! I wish I were more comfortable with that kind of work, because I think thats a good way to go. 

Ill keep watching this ticket to see if anyone else has some ideas here, but maybe I can take some time to learn more about this suggestion. 

In the meantime what I will probably do is create a different confluence space for externally approved documentation of these types and use the "Restricted" permission setting in the knowledge base for each portal.

[Elliot Reiter]

@Jim Stemper I still don't think it's necessary to have separate Confluence spaces, when it would work in one space.  As an example, have two top level pages with a child page structure as follows:

1. External Facing pages (set a page restriction for view-only for your external users here.  The child pages will inherit the view-only restrictions)

       KB Topic 1 (you can set page restrictions here for any specific external group you create)

       KB Topic 2 (you can have different page restrictions here)

 2. Internal Facing pages (the page restrictions should exclude your external users here.  All child pages will inherit that restriction).

Hope this helps.

[Jim Stemper]

That can work! Thanks for this suggestion. We will go with this!

[Elliot Reiter]

@Jim Stemper ,

You can try to use the Page Restrictions functionality in Confluence.

[Federico Scala]

I would had given the same advice, even if not sure if they apply to Confluence only or to Jira SM portal and KB as well. But it would worth a try.

[Elliot Reiter]

Yes, definitely worth a try.  Once someone clicks a link to a confluence page, Confluence security and permissions take hold.  I recommend putting the beta testers and VIP/partners in a group and set page restrictions to allow the group to view that page and any child pages.  Then this group can be set to have no permission to all other parent pages.  It's important to organize the page structure in the space well.

[Jim Stemper]

@Elliot Reiter That would work for sure, however, that would require our entire organization to learn about restrictions for all of our documentation, and I have found that the less extra things I require of our users the better (im sure you understand this). I appreciate the suggestion but im hoping for something that can be done on the admin side instead of something i need our users to learn and implement.

[Elliot Reiter]

@Jim Stemper It seems to me it will only be on the admin side.   The designated administrator of the space or the overall Confluence Administrator are really the only ones that can set Page Restrictions anyway, not everyone in the organization, so it most likely means just a handful of people.   Space admins and Confluence Admins should already know how to set Page Restrictions.

[Jim Stemper]

@Elliot Reiter agreed. That is a good point. Can you set a rule that every new page that gets created has a restriction applied?

[Elliot Reiter]

@Jim Stemper I believe automation in Confluence is only available on a Premium support plan.  My company is on the standard support plan, so automation is not available for me to give you a reliable answer.

The only rule I'm aware of is If you add a child page under a parent page that already has restrictions, the new page will automatically inherit the parent's restrictions.