Thanks Bob, I've updated the issue.

Thanks, yes, another issue can be used, but Dave needs to be aware that is isn't quite as quick as creating a subtask. Nor is either workaround very convenient or natural. I know it still a difficult requirement to meet however.

The reason I was brought here in the first place, is that one of our developers attached a secure comment to one of our public issues and included a link to an external service for the screen shots he didn't want to share publicly. That is also a workaround, but, generally, we prefer data like that be included directly in the issue and not somewhere else (expect Confluence perhaps).

Good point, Bob.

Then, a workaround could be achieved by following these steps:

1. create an issue viewable by all users with appropriate permissions on the project (Browse Project)
2. create another issue with a Security Level granted to a group and add the attachment there
3. in the issue from step one, add a comment with a link to the issue #2, optionally clicking on the Lock icon to restrict its visibility

Even an entirely new project could be created for file storage. There's a brilliant article about how to use JIRA for asset management, which principles might be useful here too.

Dave, the proposed workaround does not work as subtasks don't have their own security - JRA-5869

For us, that would cost almost as much as our Jira license itself, definitely not an option as we don't have a few grand laying around

We have implemented the Smart Attachments plugin - https://marketplace.atlassian.com/plugins/com.stiltsoft.jira.smart-attachments/server/overview - which gives us this functionality now. I know it's not native and adds an additional cost, but was worth it for us.

Personally, I consider this a security vulnerability. When you go to add an attachment, there is a "permission" icon right there. So one would assume that the permissions are set on the file as well.

This is a really big deal for us in higher education, as misinterpreting this could open the institution to a whole host of FERPA violations

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; unfortunately we don't have any plans to support this in JIRA for the foreseeable future.

Our suggested workaround is to create a subtask on the issue that you can attach restricted attachments to, and then use issue security to limit visibility of the subtask.

Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

We need this feature as well for our ticket tracking system - we're used to exchanging various versions of a document before releasing it to our customers, and I was extremely surprised/shocked yesterday when I discovered this behaviour.

So in case this matters to Atlassian, +1 more.

IMHO, this is core functionality that should be in the product and no paying customer should be paying for plugins to reach this goal. I am supposed to go live with the customers on our server based instance before the end of this month, so I will probably instruct my colleagues to use subtasks for internal attachments

I think that this should be listed as a critical issue. As an educational institution, we need to be able to attach files to the issues for future reference. However, we have to be very mindful of FERPA, and we simply can't attach files containing student data since we can't restrict who can see the attachments. This is a big deal for us! :/

hear, hear! I voted for this one too Artyom.

Hey Atlassian,

This ticket was created more than 10 years ago!

What about to share your thoughts with your customer or even just to go ahead and put this ticket into the roadmap?

Thanks,
Artyom.

Update: copying my comment from JIRA-6185 that describes the problem I have

We need a way to separate attachments in JIRA tickets by Security Level (like it's implemented for comments).

Example - I have Security Level called "Development". Comments/Tickets with this Security Level can only be viewable by QA/Development teams, but not by the Customer.
We have ticket submitted by our customer and have a discussion in it between QA-Development, but don't want to show it to the customer who is also in this ticket, so we choose Security Level = "Development" while posting comments (here is the screenshot about Security Level I refer to http://take.ms/tEA8M).

So, I want to add attachment that also can be viewed only by QA/Development teams, but not by the customer.

Happy 10th anniversary, dear JRA-3893!
(Sorry, I could not resist...)

+1 often times we are attaching screenshots or technical design documents to tickets which we don't necessarily want end users/customers to see. I know we can use the wiki to do this as well but most of our tickets require only one or two screenshots and a few sentences (restricting comments works well) so its inconvenient to have to go to the wiki, create a page and link the page on the ticket for such such a small amount of "content".

Hi Coskun
thanks for the response
I will have a look at trying to hide/remove the attachment details. Is this only for when a JIRA Issue is closed? I don't have a migration facility at the moment but I could look at writing one.

Attachments can be turned off by a JIRA System Admistrator or JIRA Administrator with Global Permissions. Navigation to Admin System page, click on Attachments under the Advanced heading. This will open the attachments page. Click edit settings and disable Attachments and turn off thumbnails and zip support. Attachments can still be seen but not added.

For future responses can you please send an email to paul.k.clark@gmail.com.

Thanks
Paul

Hi Paul, firstly thank you for your interest.

I installed and configured the "Document Vault for Jira" with eval. license in myjira.I configured to Doc.Vault Section according to group visibility.It is OK.In addition,I have a critical question.I understand that, there will be two sections (Attachments(Jira) & Document Vault ) in a issue page .Well, After I start using the add-on, how can I hide the old attachments according to group users. Namely,is migration processing possible from jira attachment to Doc Vault ?

Thanks in advance.

Hi, I have a plugin that I think should be able to do this. It's called Document Vault (https://marketplace.atlassian.com/plugins/com.redmoon.jira.documentvault) and is an independent attachments system within JIRA. Access can be confined to a group of users and/or Issue reporter and/or assignee. Unauthorised users are not able to view the attachments and the attachments related comment. There is also a project level search page to view attachments (that you are authorised to see) within the project. I am also open to suggestions if there is particular functionality you want added.

+1 for Millikin as well.

+1 here too. I'd like to record quotes / invoice documentation for my customers on the tickets without my staff seeing them.

Likewise, we record scripts and some technical data on tickets which need to be restricted to certain parties but can't do this...

I too agree that the attachment dialog is mis-leading, because it clearly states that you can restrict that post to the selected user group, but as others have mentioned, it only applies to the comment, not the attachment itself....

This is a major issue for us as well, could you please provide an update or any information about a plugin that we could use?

Keywords: Major Priority, Permissions Security...

How has this ticket been open for sooo long? With all the recent updates, i'd be willing to trade "look and feel" for security any day. Can we please at least get an update as to when we can expect this or even a workaround?

We also need this, it is so misleading at the moment and can lead to very sticky situations when you belive that you have made both a comment and attachment private but it is acutally only the comment

We also need this feature as a high priority.

In order to overcome this we had to add another project named Attachments which was used for this. This is a bug productivity loss, but seems to work. I am really interested in solving this properly.

Just running again into the situation that someone leaked source code by adding an attachment where the comment was (correctly) set to an internal user group - though the attachment unfortunately was visible for all world. I hope this request will get some attention before this issue is open for a decade...

It's vital for us that the access control for comments, also includes attachments. In today's solution you are fooled to believe that it does...

any progress on this?

I concur. Please implement this issue ASAP.

When users add attachments - e.g. screen-shots or data files for use to reproduce reported problem - it must be possible for user to determine whom s/he want to share the attachments with, as the attachment may contain sensitive information that must not be accessible by all issue viewers.

Because attachments today is readable by all issue viewers, some users do not add the otherwise extremely useful attachments needed for reproducing the reported problem!

Please add this feature to a release soon - it is overdue. This should work the same way that comment security works.

Thanks!
Russ

We tried to work around this issue using Subtasks to bundle hidden attachments with extra security level. Unfortunately this does not work because of JRA-5869. But perhaps using the workaround from JRA-5442 (make Security Level editable for Sub-Tasks) would eventually lead to a workaround we could use.

Please fix at least one of these too issues.. JRA-3893 or JRA-5869.

I can also use this feature.

The "add attachment" dialogue allows the limitation of who can view the comment that goes with the file, but the attached file itself is not restricted, which is an anomaly.

Users who do not know this might be fooled into thinking that they have limited the viewing rights for the file they have attached.

If this anomaly cannot be removed by adding the functionality we need, at least present the user with a warning that everyone can view the attachment.

It would great to have this functionality. The best would be the ability to set attachment access based on current issue status and of course groups or project roles.

Attachment functionality by email appears to be inconsistent with permissions. We have a situation were attachment functionality is removed from specific project roles. This works well when user associated with the specific project role manage issues through the JIRA interface. However, it does not when it comes to issues managed by the email handler. Emails containing attachments are processed regardless of the permission settings.

This is a crucial business requirement for us.

We also need this feature.

Fortunately we are able to hide internal conversation from our customers by limiting the comment visibility to specific "internal" usergroups. Bundled together with these comments (usually emails) are attachments with sometimes sensitive data. These cannot be included in the issue, because they would be visible to every user. So this produces a unfavourable gap between original email and jira case.

The only working solution for us is to create an internal issue inside an internal "non-customer-acess"-project and linking it with the original issue.
But this is complicating things unnecessarily by always having "internal" / "external" issues.

So, please fix this issue.

The current suggestion for customers who want to protect attachments is just protect everything, so no user can see another user's issues. The problem with this solution is it is vital that we be able to leverage previous support issues for current customers so we don't repeat the same solutions over and over again. Some customers have simple questions that we want to be available via a search engine, while others have proprietary technology and security issues because of passwords stored in the attachments. Securing all of the support requests has too many downsides:

1. When prospects are required to sign up for an account just to get information they usually opt to go with a different vendor.
2. If customer B has an identical problem to customer A there's no way to let customer B see customer A's solution, increasing our support workload dramatically.

If the answer from Atlassian is going to be the attachments have the same security as the issue, then the problem is there's no way to set the issue security either since there's only one security scheme for everything!

Well that's 30 votes now...

It will be great if Atlassian can implement this feature soon, or at the least come up with the work around to restrict the attachments.

• Dinesh

Don't hold your breath. This feature was requested almost 3 years ago. Apparently 21 votes isn't enough. Or the the feature is a lot harder than it looks. Or Atlassian has some other reason for not wanting to put it in. I've had 2 long-winded discussions with sales/support about how important this feature is for us.

We ended up having to front the entire file attachment process with a separate system that intercepts attachments the user has marked as "private" and puts them onto a private file area that only the support personnel can access. It was several weeks of effort and it's a real pain to administer.

We also really need this to make it possible to support customer without showing sensitive data from logfiles etc. but allowing them to see the functional error.

Would really like to see this asap. We would like to use JIRA to manage quotations within the project so don't want everyone seeing the attachments.

BRegards
Andrew Hurst

Recently this has come up as a crucial issue here too.

This is a feature that we'd like to see as well.

In our configuration, it is the other way around than what Chris describes: We'd like to attach files to issues that not (all of) our customers are supposed to see / are interested in seeing.

Kind regards
Axel

I second this request.

We frequently have customers send us data files that contain proprietary information. We will be setting up a public JIRA instance and need to be able to protect those attachemnts so they can only be viewed by the support personnel and the issue originator. When this feature is enabled, then one additional feature is needed - either the person provideing the attachment needs to be asked if they would like it to be made private, or we need a setting to make all attachments private by default.

For the moment we will need to track these attachments in a separate system...but as you can imagine, this greatly lessens the value of JIRA over our existing e-mail based system.