@Dave Meyer: The linked addon "Document Vault for Jira" helps when less people shall see an attachment, but my consequence of this issue is the opposite direction, i.e. some people cannot see attachments they shall be able to see. Hence, the add-on does not solve the issue for me. More details in https://jira.atlassian.com/browse/JRACLOUD-10992?focusedCommentId=2819796&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2819796

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