Tracker role-based permissioning
|Assignee:||Jean-Philippe Lang||% Done:|
What about adding rbac to trackers? One of the most requested feature i'm asked (currently, on trac) is to expose the
interface to the customers, having each customer a partial view of the issues (only the ones he issue, for instance).
Maybe things get too complicated and the whole thing may be handled differently..
The simplest workaround could be to manage a separate project for each customer, but this way the development team will
loose the global view of the project.
I can analyze the issue (and maybe implement it) if it is a sensible one.
#1 Updated by Chris Leonard almost 6 years ago
I spent a little more time researching this and thinking through
A new role would be required for this to work well, above that
of manager. I'll call this new role Exec, but it could be admin
or root or whatever. Exec would need the ability to create groups
and manage which projects are available within groups.
I picture projects being able to be shared amongst groups, similar
to the way there are many users and many projects, and they can
cross over between the two.
I think my initial suggestion of a page just like the permissions
report page would work. It could be a matrix that listed the
available groups on one axis and the projects on the other axis.
Or, a groups tab similar to the Projects tab, in which you can
add & remove projects.
This would require at least:
-a group entry in the database
-a 'groups' folder within app/views with associated rhtml files
I'm willing to fully document this if its helpful. Not trying
to be domineering or controling, but if it would help to have
a description of how to include this functionality I'm willing
to pitch in. I'm also willing to help with coding it, but know
in advance that I'll be slow (still learning ruby).
#3 Updated by Chris Leonard almost 6 years ago
This would be a great addition to redMine. As it is today (v
0.5.1) our I/T staff is using it to manage the development of
several of our web and software projects (which, BTW, redMine
is the best tool I've used for this). Our marketing department
has seen the tool and is eager to use it as well. I haven't yet
allowed them access because any marketing manager will have complete
access to our current projects. I have considered installing
a 2nd instance of rM for other teams within the company, but
that opens other issues (multiple accounts for execs, etc).
The simplest way that I know of would be to add groups meta data
to users and projects, and provide an interface to associate
them. This would be somewhat similar to the way the Permissions
report page works.
Thanks, and keep up the good work.
#4 Updated by Thomas Lecavelier about 6 years ago
I share the opinion of Jeffrey and Alessio.
I think the better way to handle this feature is to keep it simple:
redmine should stay a powerful management tool with each of its
killer^Wbig feature ready to use out-of-the-box.
Of course, the matrix idea that exposed Jeffrey is the cleaner
way, but it means that the redmine administrator have a real
work upstream to prepare the matrix and the different rights
for each group and users (which means the admin has already an
headache because of grouping users...).
The "first level" of user differentiation should be
a simple field in the user creation form (as Jeffrey said):
Based upon this, a issue created by an "external" user
is always visible worldwide, but an "internal" user
has one more field in its issue form which allow him to set the
visibility of his issue (the default scope should be configured
in the project page by the administrator).
And yes, the matrix should exist too, but should be an "advanced
feature" for big projects where the admin is not the first
developer who want to handle correctly his issues.
#5 Updated by Jeffrey Jones about 6 years ago
This would be a huge advantage and I agree that it is a pretty
important feature for most companies (and is pretty standard
on bugtrackers such as Mantis).
I would envision at a minimum a hardcoded "Internal"
/ "External" grouping. Any issue raised by a member
of the "Internal" group would only be visible to them
unless explicitely changed to "public" viewing.
A more advanced way would be to have configurable groups and
a matrix of who can view issues raised by members of each group
(rather like the current workflow setup).
Group assignment can be done when members are added to the project.
#6 Updated by gabriel scolan about 5 years ago
What a nice feature it will be !
Of course the admin would have more work to precisely tune the roles / permissions for fields for each user/group.
I currently have on my team developper and tester, who share most of the fields, but some fields are very specific for one group and the other groups should not be upset why those fields. As a manager, I'd like however to see all fields to check the coherency and understand / follow each group's work.
To complete the dream, may be it could be interesting to unable/disable editing of fields depending on the status of the issue. This would prevent misunderstanding across teams just because a decision on a solution was changed while the implementation and/or tests are on their way.
A matrix having the fields name in row and the statuses in column, with a selector, as proposed above, being the group. The value in the boxes would then be : [viewable|editable|hidden]
here is an example (not sure the assignment are correct ..)
group : Developer
fields/status open assigned resolved closed
summary viewable viewable viewable viewable
priority viewable viewable viewable viewable
description editable viewable viewable viewable
decision hidden viewable viewable viewable
tester_assignee hidden hidden hidden hidden
#7 Updated by Oyku Gencay almost 5 years ago
This was the first thing that popped up during my initial review of redmine. I've implemented this functionality. Even before reading Gabriel's post, I've started doing that the way he thought.
So the code lies on my computer. What is the best way to share it?
#20 Updated by Anthony HERBÉ 7 months ago
- Assignee set to Jean-Philippe Lang
"The simplest workaround could be to manage a separate project for each customer, but this way the development team will loose the global view of the project."
I confirm that this workaround is not acceptable because of the loss of global view of the project concernend and the duplication of it.
#21 Updated by Dipan Mehta 2 months ago
We have had a similar situation where we didn't wanted field engineers to file "Bug" but only "Incident report".
Unfortunately currently Redmine doesn't support this feature. However there is a plugin called Redmine Tracker Control which allows that specific roles (including anonymous) to create issues of specific type trackers only!
Though, I strongly believe this should be a core feature of Redmine.