Feature #12677


Private attachments for issues

Added by Eugene B over 11 years ago. Updated 8 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I would split my suggestion into two parts:

1) Defect: At 2.2.0 version a "private" comment type was added, but if you attach any document
to this "private" comment, this document is available to everyone. If a "private"
status will be applied to uploaded document as well. That would be super.

2) Suggestion: The best way would be to have not just a checkbox, where you can set a "private"
status, for comment, but a selectable field, with two strings, old "private" string, and something
like "advanced private" that will allow to select users (with chechboxes, like observers) that are
allowed to see private comment, and its attached file.

Related issues

Related to Redmine - Feature #12401: Split "Manage documents" permission into create, edit and delete permissionsClosedJean-Philippe Lang

Has duplicate Redmine - Feature #17220: Private attachmentsClosed

Has duplicate Redmine - Feature #15971: Add inside the attachemnt issue the option privateClosed

Actions #1

Updated by Jean-Philippe Lang over 11 years ago

  • Tracker changed from Defect to Feature
  • Subject changed from Attachments made to "private" comment are visible to everyone to Private attachments for issues
Actions #2

Updated by kais kais over 11 years ago

Very interesting feature

Actions #3

Updated by Anonymous over 11 years ago

(1) isn't a defect at all, since the file is attached to the issue, not to the comment.

[tl;dr warning] The way RM's database works is, everything comes back to the issue. There's a global table of issues, made unique by their issue IDs. Then there's a table of file attachments, where every issue's files are linked back to an associated issue ID. Then there's yet another table logging the notes we leave when we change an issue, and each of those is linked back to an associated issue ID. There's technically no direct link between comments and attachments. [end tl;dr]

All that aside, there's no reason why the attachments table couldn't have an extra column for privacy that would be affected by a check box at upload. This would be governed by a set of role permissions for visibility, I'd guess.

As for controlling visibility at the individual member level...that's pretty big. Having that sort of control over general visibility of private data is one thing, and hotly requested in the past. Getting that kind of control over each individual file sounds like something you'd be better off doing the old fashioned way:

Zip up the file and put a password on it. Yeah, I hate it, too, but it'll get you results faster.

Actions #4

Updated by Eugene B over 11 years ago

Regarding the (1) part, to my point of view current situation is wrong. The attachments are the part of the comment, not the issue, because the private comment and attachments was added later, even if its displayed all together at the beginning of the issue. This is the wrong part, becuase this way we are splitting the private comment into two parts, one (text) remains private and the other part is not, while the comment where the attachment was added is private. I think, all the extra "private" status should be applied to the attachments also.

Regarding the (2) part, for our company there are some situations, where we need only a fixed list of people that are bound to the project to see the issue or specific comment. Currently I can only assign a users to group with the rights to see everything private at their projects, but if a group can see it, its somehow not a private :) I understand, that implementing a possibility to select specific users that are allowed to see comment(and its attachments)/issue will require more changes to permissions. But in our case it would be good. Maybe if more Redmine users will find my suggestion interesting, and they will +1 for that and the function will be added in some of the next versions.

*making a zip with password will work, but if password is compromised, its a loss. we can of course add some links to specific folders on server which contains the necessary attachment, which will have a required access permissions, but its a wrong way.

Actions #5

Updated by Anonymous over 11 years ago

Attachments and notes are added later, yes, but that doesn't mean they're a separate entity. If I update the issue's status, target version, or priority, those details aren't separate from the original issue. They completely replace the original data, which and the old information is kept in a history log (basically a giant table that says X field was changed from Y to Z).

Redmine is just a front-end to a database, and the structure of that database is where the buck stops. Attachments are connected to comments only through the issue ID itself--a direct connection does not exist. When you upload an attachment, it's given an ID, a type, how to find it where it's stored, a download count, the ID of the uploader, a time stamp, and the file description (different from comments). That's pretty much it.

You could add a new boolean flag to file properties for privacy, but it would have to be separate from private comments, and you'd have a second 'Private' checkbox next to each file you upload. There's also the fact that the author and assignee would always be permitted to see those files.

For (2), I think you might be trying to do way too much within one issue ticket. If a single ticket has one file that two people should be allowed to see and another file that three different people should be allowed to see and comments that an entirely different set of people should be allowed to see, it's time to start filing separate tickets. Adding a multi-select user list next to every single field would make Redmine (a) ugly, (b) intimidating to new and infrequent users, and (c) have a nightmare of a database to track all that data.

If it's absolutely critical that you have that level of control over every single detail of an issue, supplemental tools (email, SharePoint, something) are the only way to go. You need to be storing files in a way that you have direct access to its permission properities and can grant levels of access based on network credentials to people on an intranet or VPN. Drop an intranet hyperlink into a private comment and call it a day, IMO.

Actions #6

Updated by Ramesh S over 11 years ago

+1 for private attachment. For example, I am trying to setup one redmine project per customer. And here, 'customer', 'manager' and 'developer' will all be contributing against this issue with various discussion points and documents. Thanks to the private fields feature provided in the recent Redmine release, I am able to manage the internal discussions by keeping it within 'developer' and 'manager' and not expose them to the 'customer'. Similarly there are situations where certain internal documents that are exchanged between 'developer' and 'manager' or between developers are also uploaded against this issue and such documents, sometime, are purely internal and need not go to 'customer'. So, it would immensely help to tag a document as 'private' and have a privilege setup in redmine such that private documents are not available to certain user roles, such as 'customer'.

Would love to have this feature in redmine.

Actions #7

Updated by Deoren Moor over 11 years ago


I too would find this very useful.

Actions #8

Updated by Jai prakash over 11 years ago


Very usefull feature. This along with private comments and private fields means no more internal project/external project , issue tracking will be much easier.

Actions #9

Updated by Ramesh S over 10 years ago

I have finally managed to create a private attachment feature in Redmine. I have made it against a released version of Redmine and yet to make it for trunk revision. If anyone is interested, let me know. When I get some time, I will post the patch here. If time permits, I will make it for the trunk revision.

I am in the process of making unit test cases also.

Actions #10

Updated by Eugene B over 10 years ago

Good news, if integrating with current Redmine installation is not hard, I would like to try.

Actions #11

Updated by Toshi MARUYAMA almost 10 years ago

Actions #12

Updated by Jérôme BATAILLE over 9 years ago


Actions #13

Updated by Alex Gotardi about 9 years ago


Actions #14

Updated by Toshi MARUYAMA about 9 years ago

  • Description updated (diff)
Actions #15

Updated by Go MAEDA over 8 years ago

  • Has duplicate Feature #15971: Add inside the attachemnt issue the option private added
Actions #16

Updated by Tobias Fischer almost 8 years ago


Actions #17

Updated by Tobias Fischer almost 8 years ago

Can this feature be considdered for next minor release 3.4?
This is a show stopper for using the "private" comments feature...

Actions #18

Updated by Eugene B almost 8 years ago

I hope one day this private feature will be realised properly. We are mostly using Redmine as task tracker, private message feature is not required so often, but still we need it sometimes. Currently we have a workaround to split task and to post its part at the another project with different access rights, but its a bad, clumsy solution. too many subproject appears, and if someone will move a task to another project - privacy is lost.

Current private realisation is almost useless - its not apllied to attachments. Also, you have only one global list allowed to see private comments (list can be set at the redmine role setup) But sometimes you need to share a file or comment with specific person only. We need to have possibility to select who will have access to each new private comment and its attachments.

I see it this way: once you select "private" status for a comments - a popup window appears with a list, similiar to observer selection, where you need to select who can view this comment and attachments. (groups or specific users)

Actions #19

Updated by Julian Morales almost 5 years ago


Actions #20

Updated by Eugene Smirnov over 4 years ago

Eugene B wrote:

Good news, if integrating with current Redmine installation is not hard, I would like to try.

+1 !

Actions #21

Updated by Dominik Ras over 4 years ago


Actions #22

Updated by Eugene Smirnov over 4 years ago

This is reali need!!!
Attached file in private commente don't private!

Actions #23

Updated by Eugenia B. almost 2 years ago


Actions #24

Updated by Martin Mayr-gebhard over 1 year ago


Actions #25

Updated by Gerd Jünger over 1 year ago


Actions #26

Updated by Jan S over 1 year ago


Actions #27

Updated by j l over 1 year ago

Same here, we discovered the hard way that attachments made while writing a private comment were not private at all... We would love to have that possibility!

Actions #28

Updated by Eugenia B. 8 months ago



Also available in: Atom PDF