Redmine

Very interesting feature
+1

(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.

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.

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.

+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.

+1

I too would find this very useful.

+1

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

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.

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

+1

+1

+1

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

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)

+1

Eugene B wrote:

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

+1 !

+1

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

+1

+1

+1

+1

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!

+1

+1

+1

I fully understand that an attachment is linked to the issue, not to the note. However, in practice, attachments often serve as extensions or supplements to the note's content, so they are de facto considered semantically part of the note.

There is, in fact, a real risk of a privacy breach if a user publishes private information along with a note.

Moreover, the paradigm of "attachments belonging to the issue, not to the note" also prevents users from sharing private information that cannot be written directly in the note but can only be provided as a file.