nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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:

2021-10-20 08_50_03-StagesBike - Knowledge base - Service project - JIRA.png

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?

Comments

Elliot Reiter_zg1zk0

@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_zg1zk0

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.

Matt_ogf1oa

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

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

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_ogf1oa

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.