Redmine

A patch was proposed for this feature by Jeffrey Jones.
http://rubyforge.org/tracker/index.php?func=detail&aid=10381&group_id=1850&atid=7162

I may integrate it in the future, so any comment is welcome.

Hello,
I almost convinced my bosses to use redMine in a presentation yeasterday :)
The issue that was on the table with it was exactly these private issues.

The patch proposed by Jeffrey Jones is about internal/external users.

I'm asking now for the ability when reporting issue to make it private for the user who reported it. There has to be a permission for this feature - View others private issues.
redMine is a great innovative tool, and we want to use it as a project management solution, by posting to it not only developers tasks but the jobs of project managers. It suits our organization for now but, the lower levels of the hierarchy should not see the work of the higher level.

I hope you understand me :)
Thanks and regards,
Nikolay

Hi,

I almost convinced my bosses to use redMine in a presentation yeasterday :)

I'm very proud of it :-) Thanks

I understand your need. It's different from internal/external issues.
Instead of adding one more flag on issues, maybe I could implement a common solution:

• just a "Private" flag on issues
• a new permission "View private issues" at role level
• a "No private issue" flag on user accounts

If a user has a role with "View private issues" permission, he will see private issues on the corresponding project.

If a user has the "No private issue" flag checked on his account (not modifiable by himself of course), he won't see any private issue and won't be able to create private issues. It could be set for clients for example.

What do you think ?

Hi,
I think this is the solution, Jean-Philippe. :)

There is something I don't understand indeed...
What is the meaning of the "No private issues"?
If a user has "View private issues" or just "Private issues" in the role "Clients" for example, maybe he should not be allowed to see and create them... Or I missed something?

Thanks,
Nikolay

It's just to allow a same role to be used for internal and external (eg. client) users, as requested by Jeffrey Jones.

That role could have the "View private issues" permissions, but you can prevent clients who have this role to view private issue by checking "No private issue" on their account.

Got it, but will it works like the patch Jeffrey proposed?

Because I think the internal/external feature is a whole new solution for redMine, because external users are commonly clients in Trouble Ticketing sistem. Jeffrey made some filtering on assignment of issues to internal/external users etc...
This separation of the users in redMine will make it not only project management and issue tracking, but and trouble ticketing system which on its side is great :)

Thanks,
Nikolay

Hi,
another thought: when creating an issue and assign it to somebody, there has to be a possibility to make it private for that user, so only he can see it (like the boss assigns tasks for project managers, but the developers are not allowed to see this tasks).
I thinking of a tree, in which the lower level users don't see the issues of higher level users.

Thanks,
Nikolay

Heh, I will soon be leaving the company I am currently employed at and unfortunately the main drive to install redMine will leave with me. Therefore I can't really give much more information.
Off the top of my head this sounds like it is more complex than a simple user based internal/external separation.

Cheers

RJ

An idea similar to private issues is, I think, a private task list - so not to clutter "official" trackers.

Each user could be given a simple tracker for his daily tasks/duties.

First of all, Redmine is a great product. I liked the workflow feature and I see enough potential to be customized for purposes other than project management. Only if I could make all issues visible only to certain roles, and for others only their issues are visible.

In my opinion, it would be great if this feature can be enabled as part of permissions - something like "View All Tickets" could be a permission which is set to checked by default. If we uncheck, members with that role can see only their ticket.
That also means, they will not be able to see others issues, activities, calendar, issue summary etc.

I am not sure how difficult the implementation is. I am new to Ruby and trying to figure out how permissions work in Redmine (some hash table?)

The other "issue" is the name "issue". I would have preferred some neutral terms like "ticket".
Anyway, I edited en.yml and changed the word issue to ticket.

I agree with Geordee - really great software you created there, Jean-Philippe. As you know we recently started using it for TYPO3 (http://forge.typo3.org).

Private issues are also one of the most important features we will need for TYPO3. We have a security team which takes care of any security issues. Currently we track them with Mantis. All security issues are submitted as private issues which only the security team can see.

I propose that a "private" flag can be set for a whole tracker. All issues for that tracker are not visible to the public (but probably to the team members). The question is, how we can give the security team access to all these trackers without having to add each team member to each project. The easiest - but not very clean -solution would be to let all security team members be administrators. But maybe there are alternatives?

I agree on that point: private issue (this may be called "security issues", too) is a must-have for redmine. Private trackers should be easy to get too.

Thanks for your contributions. Here is what I propose:

• a '_private_' flag on issues (so that the tracker won't be the only way to set an issue as private)
• a '_view private issues_' permission at role level
• an additional setting at account level to set the ability of the user to see private issues, with the following options:
  • never: the user can never see any private issue
  • always: the user can see any private issue
  • according to his role: the user only see private issues on projects for which he has a role that is allowed to view private issues

Robert, you could use this option to enable security team users to view any private issues without having to give them a role on all projects.

A flag could also be added at tracker level so that an issue attached to a private tracker is automatically private.
A user should be able to view a private issue if he is its author or assignee, whatever his permissions are.

One more question: who should be allowed to create or set issues as private ?
For example, anyone could be allowed to create private issues but only specific role(s) could be allowed to set an existing issue as private.

What do you think ?

Hi,
Jean-Philippe, all your proposals are pretty enough I think.
Only that:
Robert, you could use this option to enable security team users to view any private issues without having to give them a role on all projects.

I can't get the meaning. If a user is not assigned to a project with a particular role, he don't see any issues in this project (not public project), right?
Then, how he will see the private issues? Am I missing something?

Regards,
Nikolay

Nikolay, I was speaking about public projects (which is the case of Robert I think).
Of course, if a project is private, only its members can see it.

Great! I think it's a really good start.

Regards,
Nikolay

It sounds good to me, too.

Hi Jean-Philippe,

great to hear that you want to work on that feature. In my opinion all of your proposals make sense and they would certainly satisfy our demands.

One more question: who should be allowed to create or set issues as private ?
For example, anyone could be allowed to create private issues but only specific role(s) could be allowed to set an existing issue as private.

In our case anybody should be able to create private issues and it would be okay if anyone would be allowed to set an existing issue as private. However, I could understand if someone needs the feature that only certain people are allowed to mark existing issues as private. Maybe that shouldn't be an extra feature but rather be determined from the rights someone has to edit a whole issue.

Best,
robert

I'd just like to add my voice to this one too. I will quickly out line our use-case, which i think is covered by the above description that JPL described above.

I have a team which work on a project. There are many non-team members which create new issues (features, bugs, etc). I would like to have the non-team members able to create items, and then the team "update" the items (with notes) which are not viewable by the non-team members.

It would be helpful to have an option to make "updates" private by default.

Thanks

This could be accomplished by adding a "private" flag to journal entries.

Sounds good to me.

Private bugs are also an issue for us, however our use case is I believe slightly different - I'll put it here in case it's a helpful. As I understand it, what you are proposing above is the ability to restrict certain issues to effectively "superusers" - in case they are sensitive.

Our use case is if we use redmine to track bugs in a product, we would want company Foo to raise bugs and also company Bar to raise bugs in the same project - however whilst Foo could see all bugs Foo had raised, we would not want them to see bugs that Bar had raised (and vice versa). This seems very similar to the proposed solution, but rather than private/not-private it requires the ability to set them private/not-private at a company wide level (to be honest, even if it was limited to "person from Foo who raised the bug and all developers" that'd probably be sufficient).

Thanks - redmine looks very interesting!

Adrian, your request concern another matter: user-groups. There's a bunch of feature request about that, like #1018. Once this feature will be implemented, another improvement will be to enable users from a certain group to view restricted/private/security trackers.

Anoter Idea:
Why not let us use Custom Keywords for that.
Let us specify something like "Use this Keyword as permission"...

    * just a "Private" flag on issues
    * a new permission "View private issues" at role level
    * a "No private issue" flag on user accounts

I can name Keywords: Internal, externals Developer, High security team, ....

I just imagine the mess with keywords: this issue went just private. Imagine all the other issue that become private without warning. Sound funny :)

YES, PLEASE! There is a need for some way to hide certain issues from the customer. We use Redmine for tracking our software developemnt project. Not all issues are for the customer to be seen.

Simply make a checkbox "Private" which will make the issue invisible for customers.

I sort of like the idea of keywords. Yes there is some complexity there, but its generality just seems naturally appealing to me. More so than coding a hodge-podge of private/public, personal/non-personal, internal/external, financial/non-financial, and so on.

I can also think other levels of access. For instance, in our shop the developers would never want to prevent the user from seeing the internal of what we do, they generally don't want to. It would be nice to be able to hide developer tickets from non-technical staff by default, but allow them to choose to see them if the want.

We are using Redmine for internal purposes. We would like to see "Private tickets" as Nikolay Solakov described them: a user should be able to see only its own reported tickets.

P.S. I opened issue #1491 asking same thing than I found this. Sorry.

P.S. I opened issue #1491 asking same thing than I found this. Sorry.

Duplication relation marked, #1491 closed. Thank you for pointing it out.

I dont think all the different posters on this page are talking about compatible use cases (or at least the proposal being proposed by Jean-Philippe Lang will solve some users problems but not others). One of the blissful things about Redmine is that so far it achieves so much out of the box with a 'lightness of being' - it is not weighed down by hundreds of modes, options and checkboxes. What I am worried will happen here is that this proposal will be implemented, but will only silence 50% of the requests so then further layers of control get put on top until you end up with a Lotus Notes-esque multi layered security model nobody can understand...

Here are some real life scenarios as far as I can tell from the discussion:

A - Customer vs Customer

Acme CAD systems wants to collect bug reports from clients Boeing and Airbus, but clients should not be able to see each others issues.

B - Internal vs External

Acme Banking Systems wants to let the customers have access to file and track issues but dont want them to see issues found by the QA/QC team during development.

C - Internal vs Internal

Apple computer want the general development team to work on outstanding issues but keep new features tightly controlled and visible to key developers only.

The proposed solution (private flag and associated permissions) is too blunt to solve all these needs - it marks some issues as private and then grants some roles the ability to see private issues. This will solve the goal of B above (since internal roles will be senior to external roles) but will be a problem for A and C because they are peer to peer type access control problems (although clearly there are workarounds).

Perhaps instead we could implement user groups (as requested elsewhere... ) as collections of users. Allow issues to have project visibility or group visibility (perhaps have a group field and if null visibility is default). Neatly partitions access within the members of a project and separately from role. Works great where multiple clients exist in the same project ect. Completely backwards compatible.

I think the group visibility is great.
But just keep in mind that when a new bug/feature is raised, "someone" need to setup the visibility for each group; this could be a long uninteresting work, and shall be reserved to some people (Project Leader for example) ... So depending on the cases you've presented above, default visibility should be automatically setup.
For example,
- when Boeing open an issue, everyone can see within ACME (or some groups only), excepts the one registered as Airbus.
- when an issue is open internally, everyone can see it within ACME (or some groups only), and customers can not see them.

To summarize, a configuration panel shall exist per group to determine the default visibility to set up to the other groups in case one member of a group raises an issue.

Good points. To properly suggest an answer I need to solicit feedback on another question first. If Groups get implemented should they be exclsuive or not (ie can I belong to multiple groups?).

If groups are exclusive they are fairly easy to implement - when adding members to a project there would need to be an additional column group. A project member could be assigned to 0 or 1 groups. Alternatively groups could be a global attribute (same across all projects) in which case users would be assigned to a group from the user admin screen.

Either way you could set a project level flag: Default Issue Visibility: <Group | Project>

Then all new issues created by anyone would default to the group that person was a member of if:

1. That user was in a group (group not null)
2. That project had a default visibility of Group

On the other hand if Groups were implemented in a more flexible way where any user could be a member of any number of groups then it gets harder because the above logic would not work. I am having difficulty thinking of a fooproof mechanism in that scenario.

Ewan Makepeace wrote:

If Groups get implemented should they be exclsuive or not (ie can I belong to multiple groups?).

From my POV, exclusive groups are just useless: they could be replaced by a system of credential copy. Of course, non-exclusive groups are far harder to implement, since we have to define rules of precedence between groups rights, but that's the only way to get powerfull right management.

Am I right in assuming that the original patch by Jeffrey Jones from 2007-04-30 no longer works? It seems the source code has changed quite a bit since then, the patch won't apply anymore.

Did anyone ever update it? It would make a nice stopgap until private tickets in 0.8 are available...