We have implemented Jira Service Desk with a Knowledge Base configured to one of our Confluence Spaces. We have enabled anonymous access to so anyone can view the portal and browse through the support articles we have created.
What I am looking to do now is turn off the ability to submit a ticket from a KB article. We have some articles that prompt them to contact someone else for an issue, but users are still clicking the button that is located within the KB article and submitting the issue to us.
I attempted to updated permissions to restrict anonymous ticket submission, but then it won't allow a user to even access the portal and see the KB articles without logging in.
Any thoughts or suggestions?
Hello Kayne,
Welcome to Atlassian Community!
Reading the details you provided, I believe that you are talking about the link on the bottom of the article, please correct me if I'm wrong.
If that's the case, currently it's not possible to edit or remove this option.
There is a feature request suggesting improvements for that:
Please, click on vote and watch to receive updates about the feature.
Regards,
Angélica
@Angélica Luz Hi Angelica, I know your answers is two years old, but I hope you are still with Atlassian and read this.
If I understand your answer correctly, there isn't any way to set up the knowledge base in a way that customers can see it but not be able to create a support ticket, correct?
In our particular case we don't have the knowledge base or support portal publicly available for anonymous users.
In fact, we don't use the knowledge base for customers yet but are considering it. The challenge I see is: On the KB tool that we use today we have much more users than who's allowed to create support tickets via JSM.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for reaching out to Community!
It's possible to remove the permission to create tickets on a specific project, but it would affect all customers, it's not possible to restrict a few ones.
Other than that, if you want a project where people need only to view the articles and not create tickets, you can create a specific project for that and link the Confluence space, but hide all Request types from the portal.
As all Request types would be hidden, then customers wouldn't be able to raise requests.
To set a Request type hidden from the portal, it's just necessary to remove them from the groups.
Regards,
Angélica
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Angélica Luz . Understood.
However, this would have a couple of drawbacks, right?
Either I now have to maintain users for both projects separately, meaning all users for the "request-portal" also need to be maintained for the "KB-portal". (Not sure how integrated the KB articles then are in the "request-portal" when submitting a request.
Or I have to link the same KB to both projects: This allows me to maintain one user group in one project, the second one in the other. But then I have to maintain the KB categories and KBA-assignments to categories in both projects.
Please tell me I'm wrong and there's an easy solution to those two problems ;-)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, @Christian Happel. Did you ever receive confirmation of the items you posted above? I am working with a similar use case and am curious if the product functionality has changed since 2022.
If you or @Kayne Kreitzer found acceptable workarounds, would you consider sharing?
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Casey Jeane,
unfortunately no good news from me.
We only use one project and one portal for everyone:
We ended up being a little bit more restrictive on who we give access to the support portal, and at the same time accepting that some of them could create support tickets while they shouldn't. This is working quite well and hasn't led to any support tickets from people we don't want to.
Best regards, Christian
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.