Private/hidden issues (Feature #189)

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?

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.

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.

Exactly.

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.

+1

Any chance that this feature would be implemented?

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.

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.

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.

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

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

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.

+1 very much needed here in my team

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"