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)

Added by Steffen Gebert at 2011-02-13 09:09 am. Updated at 2012-11-12 02:22 pm.

Status:Open Start date:2011-02-13
Priority:Normal Due date:
Assignee:- % Done:


Category:Issue tracking
Target version:-
Remote issue URL: Affected version:


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!

Related issues

duplicated by Feature #701: Private Issues and Private Comments Declined 2011-11-15


Updated by Aleksey Zapparov at 2011-02-13 03:18 pm

Isn't it easier to have a separate "closed" project for such purposes? Or I didn't get the main killer idea of this proposal?

Updated by Steffen Gebert at 2011-02-13 03:20 pm

Okay, setting up a hidden project might be a workaround. However, I assume this requires to maintain all the team members twice.
Idea is to be able to hide reported issues and make them only available for team members.

Updated by Jan Wedekind at 2011-02-13 05:50 pm

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.


Updated by Tim Craig at 2011-02-13 09:26 pm

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.

Updated by Anton Lukashev at 2011-04-07 09:05 am

Any chance that this feature would be implemented?

Updated by Holger Just at 2011-04-07 10:19 am

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:

  1. Re-build the current permission system to be much more granular
    • That includes granular permissions on object attributes
    • Global roles
    • Complex permissions
  2. Using this framework, private issues are probably rather simple to implement
  3. Profit

The ideas for that permission rewrite are tracked on New Permissions.

Updated by Anton Lukashev at 2011-04-11 06:08 am

Thanks for answer. Waiting for any result and when you'd need some feedback from trunk while implementing any step you mentioned - you can count on me.

Updated by Peter Olson at 2011-05-02 08:55 pm

This is marked as closed on Redmine now. It doesn't look like its as complete as you talked about above, but even basic implementation would be nice.

Updated by Jan Wedekind at 2011-07-13 11:53 am

+1 on this. Would be a big benefit for us too.

Updated by Kieran Kelleher at 2011-12-29 03:15 pm

+1 - I need this feature right now. Thanks to ChiliProject team for all your hard work.

Updated by Jan Vlnas at 2012-05-23 08:47 pm

Shameless plug: I've extracted this functionality into a plugin for ChiliProject –

It's still pretty basic and needs to be battle-tested, but so far gets the job done.

Updated by Frédéric LEUBA at 2012-08-24 12:41 am

+1 very much needed here in my team

Updated by Manuel LG at 2012-11-12 02:22 pm

And why not set the visibility to a list of users or groups instead of mark it public or private? Something like "Visibility: Public" OR "Visibility: Mark, Jan, My Group"

Also available in: Atom PDF