• 30
    • 48
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      Atlassian Update – 4 January 2016

      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.

      There is add-on for JIRA Server available on the Atlassian Marketplace that may help resolve this request. However, for fine-grained security for files, we recommend keeping attachments in a dedicated document or file management application.

      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

      Would like to be able to limit access to attachments to a certain group – similarly to limited access for a particular comment added.

      Before this is implemented, I'd suggest an expicit warning on AttachFile page saying CommentViewableBy does not affect visibility of the attachment created with that comment.

            [JRACLOUD-3893] Attachments with access limited to a group

            Georg DE added a comment -

            @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

             

            Georg DE added a comment - @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.

            Dave Meyer added a comment - 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).

            Bob Swift (personal) added a comment - 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.

            Ignacio Pulgar added a comment - Good point, Bob. Then, a workaround could be achieved by following these steps: create an issue viewable by all users with appropriate permissions on the project (Browse Project) create another issue with a Security Level granted to a group and add the attachment there 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

            Bob Swift (personal) added a comment - 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

            Chris Myers added a comment - 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

            PulseI added a comment -

            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.

            PulseI added a comment - 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

            Chris Myers added a comment - 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

            Dave Meyer added a comment -

            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

            Dave Meyer added a comment - 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

            Gabriel MOSCALU added a comment - 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

              Unassigned Unassigned
              4fbb47c42ac4 Denis Yurkin
              Votes:
              263 Vote for this issue
              Watchers:
              161 Start watching this issue

                Created:
                Updated: