ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Private/hidden issues (Feature #189)
The possibility to hide open security issues from the public is a crucial point and prevents us from using Redmine as our main bug tracker.
This feature now finally made it on the road map for Redmine 1.2.0.
What's your opinion towards this feature? Are you planning to implement this early, too?
Thanks for your efforts!
|duplicated by Feature #701: Private Issues and Private Comments||Declined||2011-11-15|
Steffen Gebert wrote:
Okay, setting up a hidden project might be a workaround. However, I assume this requires to maintain all the team members twice.
Yes, this is precisely what we are doing right now. And yes, you need to maintain member lists twice.
There are other caveats: we need to create timesheets for the projects. Effectively, I have now two projects I need to add up. That's not rocket science of course and do-able, but not convenient. And for non-experienced users, it can create confusion as to where report issues.
By the way, in our scenario it's not about security fixes -we work a lot on non-software projects with external partners. These projects are not public anyway. But sometimes it would be useful to keep issues "internal" to the company since we don't want to discuss it with everyone, but within the same project.
Idea is to be able to hide reported issues and make them only available for team members.
Private issue's would be an excellent feature and one that would hold me back from moving to Chiliproject as soon to be implemented in Redmine.
We have similar need were external users can only see issue's they created and internal project team can see all issue's.
Just to make our point clear here. We are very aware that this feature is an important one and we are actually working towards having this. However it is still going to take some time. Please let me explain why.
Private issues as a concept is rather "cloudy". That means, it's not initially clear what a "private issue" is, most importantly, who should see the issue and who can edit it. The first answer to that could be "everyone who is involved". But who is actually involved? The author and the assignee? Any watchers? All project members? ... This rather hard to get right as to satisfy more than the simplest needs.
A minimal approach would be to introduce a new flag called private to issues and matching permissions called "edit private issues" and "view private issues" which deny access to anyone who does not have that permission to flagged issues. To my understanding, this is the approach that JPL plans to implement for Redmine.
That approach has several issues though. You can't have multiple groups there. And you still can't decide on access more granular. This is e.g. required for a help desk scenario where everyone should only see her own issues but not the one from others. You also need workflows here. Also it is still not clear who should actually see those private issues. What about a customer who adds an issue that should be private, does she still see it? What about the various reports? What about booked time on private issues? ...
You see, it is not as simple as it initially seems if you try to make it a generic and broadly usable feature. That said, here is our rough plan:
- Re-build the current permission system to be much more granular
- That includes granular permissions on object attributes
- Global roles
- Complex permissions
- Using this framework, private issues are probably rather simple to implement
The ideas for that permission rewrite are tracked on New Permissions.
Shameless plug: I've extracted this functionality into a plugin for ChiliProject â€“ https://github.com/jnv/chiliproject_private_issues
It's still pretty basic and needs to be battle-tested, but so far gets the job done.