Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Allow issue export only for defined users?

Hi all,

I'm trying to find a solution to restrict the possibility to export a single issue or the result of an issue search to a defined group of users.

Background of the question: we have some user which are allowed to view all issues in our backend (Jira Software and Service Desk) but are no Service Desk Agents. Therefore they should not see any internal Service Desk comments. For the issue we solved this by hiding the activity panel via Scriptrunner. But when they export an issue all comments are exported. So we would like to restrict that.

I tried this workaround ( but it is only possible to hide the export button on the issue navigator page and only for ALL users.

Any ideas?

Thanks in advance and kind regards


2 answers

1 accepted

0 votes
Answer accepted
Andy Heinzer Atlassian Team Oct 31, 2019

Hi Susan,

I understand that you are looking for a means restrict which users can export Jira issues and the comments within.  I can see why you might want to restrict these internal comments, however there is a flaw in this the ability to restrict this.

The ability to see internal comments of a Service Desk project is not actually only granted only to Service Desk Agents.  Technically all licensed Jira users that have permissions to that issue will be able to see all the public and internal comments on those issues.  Since that is the case, the exporter in Jira is also expected to include those when that user is doing an export.  This is by design though. It is meant to allow Jira Core/Software licensed users to interact internally with support agents.  Meanwhile only Service Desk agent users can actually respond with public comments to the customers.

This private/public comment behavior varies slightly though if you were using an issue level security scheme.  The security schemes can let you specify which issues and/or comments within that issue should have restricted visibility.  These can be applied to any type of project in Jira Server (Business/Core, Software, Service Desk).  Usually these are used to restrict a comment or an entire issue to only be visible to users in a group or a project role.

Essentially, what I am getting at here is that the way I would suggest to address this problem would be to lock down the project permissions first and if necessary implement a security scheme on such projects to completely prevent such users from seeing that content completely in Jira.

I'd start with checking the project permissions.  If these users should not even have access to see these issues in this project, then adjusting the project permissions so that they cannot browse issues in this project will effectively hide all those issues to those users.  This will prevent them seeing the issue in Jira and in turn that issue will not exist when that user does a search in the issue navigator. 

If these users need to be able to see the issues, but just not specific comments, well, it gets more complicated here, because the ideal way to implement this would be to apply an issue level security scheme to that project, and the apply a security role to such comments as they are made.   This way the users can still see the issue and search for it, but when they view the issue or export it, they only get back the comments that their account has rights to see.


The KB you cited can be helpful to prevent users from using the export button on the page, but that method does nothing to prevent users from using REST API calls to perform essentially the same tasks.  Also if the users are advanced enough, they could simply edit the HTML using a browsers developer tools to make that button re-appear for them.  Those users still technically have the permissions to use that function even though we might have implemented a CSS hack to hide the elements to the end user.

Which is why I think it would be best to push for on the front of checking/adjusting the permissions of those users first.  And then if need be implement issue level security as well.  These are at least two built in pieces to Jira that exist to manage these kinds of security concerns natively.  In turn if you implemented these to handle this, even requests then made via the REST API by that same user would still return only what they have permissions to see, the same as the issue navigator always will.

I hope this helps, please let me know if you have any concerns or questions about this suggested approach.


0 votes

As you wrote, you can hide the export features from all users. That will work, but the cost is that everyone will completely lose the feature.

You could eventually try this:

  1. Hide the built-in export features. These are hidden for everyone.
  2. Use the Better Excel Exporter and Better PDF Exporter apps, both of which enable you to select users and groups for each export option. See the screenshot.

With this combination you can have export options that can be restricted flexibly.

The cost is that this solution includes paid apps. But you get much more than just more control over visibility. (Disclaimer: I am working at Midori, the team that develops these.)


Suggest an answer

Log in or Sign up to answer

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you