We are configuring our service desk for a school and we want some articles to be restricted viewing for employees only. Currently it appears I can't restrict that kind of access and our employees don't need anything beyond viewing permissions. Does anyone have a work around for this or know of a plugin that will allow Confluence to read our active directory categories for viewing permissions?
Hello Melody,
Happy to help!
Can you confirm what version of Jira Service Desk and Confluence you're running? Is both Jira and Confluence using Active Directory now as the primary user directories?
You can restrict viewing on a Confluence space for licensed Confluence users, or allow anonymous users access. If you link the space to your JSD Customer Portal, then your JSD customers will be able to view the Confluence documentation via the Portal.
Regards,
Shannon
Shannon-
Thanks for the response. For Jira ServiceDesk we are on server version 8.3.4. For Confluence we are on server version 7.0.1.
I don't believe we have integrated Confluence with AD yet. Which may be the first problem. If I understand the setup correctly, what we want to do is allow anonymous access to our users, but allow the AD to filter what they can access. Currently it appears the only way to filter access is if all our users have licenses, which as I mentioned is unnecessary for our broad user base.
We are a school and I need to allow students and faculty to share the same help portal, but have different access to BOK articles.
Does that clarify what I am asking?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Melody,
I'd just like to take a moment to clarify further exactly what you're asking, just so I give you the right information. From what I understand, you have a Customer Portal in Service Desk, which is linked to a space in Confluence. The space contains the articles that your students and faculty need to access. However, you want to split which articles they have access to (e.g. some articles are faculty-only and some are student only). Is that correct so far?
If your users and groups are in Active Directory, Confluence needs to see those users to know whether or not they should have access to an article in Confluence. Therefore, you would need to connect both Confluence and Jira to AD and synchronize your users so that Jira and Confluence share the same user base. You just want to make sure that the users that get synced from AD into Confluence do not have can use permissions if you don't want them to take up a license. This way, if a Confluence user sees jsmith try to access an article, it'll see that it's an active JSD customer, and has permission to view the space, even though that user isn't taking up a Confluence license. If jsmith only exists on Jira and AD, then Confluence won't know about it, and can't allow access.
Anonymous access essentially means access for people who do not have a user account at all, so only users who are visiting from the internet who are not currently logged in (therefore, not your students or faculty.) You can set this up in Confluence so that specific spaces allow public (anonymous) access, but you can't control this beyond that.
In Service Desk, you can set specific permissions for the Knowledge Base access. If you review that article, it lets you know the difference between the options: All active users and customers (not licensed in Confluence, so jsmith in my earlier example), or all licensed users (anyone who is also taking up a license seat in Confluence). If you need to split the access across 2 different groups then you might consider having separate Customer Portals for these users.
I hope that's clear, but let me know if you have any questions about that.
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.