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 over 12 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 over 12 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 over 12 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 over 12 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 over 11 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 over 11 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É about 7 years 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 over 6 years 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.
#23 Updated by François Pouilloux over 6 years ago
Ross Hendrickson wrote:
Same here...could really use this to allow for people outside development to create suggestions and bugs, but keep them from being able to create features.
Same need here, reporters can create bugs but features are in the hands of the development team.
#25 Updated by Anthony HERBÉ over 6 years ago
Dipan Mehta wrote:
However there is a plugin called Redmine Tracker Control which allows that specific roles (including anonymous) to create issues of specific type trackers only!
But this plugin only give restrictions on creation but not on view issues of tracker types.
#27 Updated by Ty You over 6 years ago
Holy cow, this issue is #285 and over six years old, and we're still asking what the feature means?
It's been "plus-one'd" to death, what the heck has to happen to get it addressed?!? Not having this feature is a major setback.
I gave the "Redmine Tracker Control" a shot but it crashed my 2.2.x installation.
#29 Updated by Lázaro Hermoso about 6 years ago
- File Issues Visibility.JPG added
Definitely and improvement!
Maybe it could be implemented by adding more functionality in 'Issues visibility' within Roles and Permissions Administration Menu.
!Issues Visibility.JPG!When selecting a Role you can select Issues Visibility between:
- All issues
- All non private issues
- Issues created by or assigned to the user
- In my opinion a solution could be to add here the functionality of selecting the trackers that each role can view
In #8488 it was achieved to let watchers view issues eventhough their permission was set to 'issues created by or assigned to the user'. This is somehow a solution but it would be annoying to add users as watchers to every single issue.
I am sorry that I am not a developer and I cannot help with the code... :(
#30 Updated by David Marín Carreño almost 6 years ago
Please add this functionality. We have a tracker that is meant for internal use, and some customers insist on adding issues to this tracker because its name seems more convenient to them... And after that they keep on complaining about they can't change the status of these issues...
#31 Updated by Jack Casas almost 6 years ago
+1 to request this
I installed Redmine 2.4.3.stable for the first time in my company yesterday. After one day of use, I only miss this issue!
We need our customers to only be able to open Support requests. Features and Bugs are only for internal use!
We can't use "Issues created by or assigned to the user" because the customers controller has to see all the active support requests!
We need selecting the trackers that each role can view. Thanks!!
UPDATE: I now have this feature thanks to the plugin http://www.redmine.org/plugins/redmine_track_control
The version that is working for my latest version 2.4.3 is:
I still believe this should be included in the core pack.
#35 Updated by Maxim Krušina about 5 years ago
+1 ... I really hate t create separate projects for client support... (now I have to create just one more :). It would be really great to be able just add tracker for client support, so it vill be visible to different roles, like:Client support tracker:
- Clients (group) - visible
- Project Managers (group) - visible
- Developers (group) - not visible
- Clients (group) - not visible
- Project Managers (group) - visible
- Developers (group) - visible
#37 Updated by mike B almost 5 years ago
In our company we have many issues that are necessary to have other "non-members" of the project to be involved in an specific issue but it is not necessary nor it is wanted for them to have full access to ALL of the issues in the project, only the ones they have been added as "watchers" to.
one workaround I tried was creating a group called "Watchers", adding ALL of the users to that group. I then set the permissions for that role to where they cannot see issues in a project unless it is assigned to them. The group's permissions are as limited as possible.
Just adding a "Watched issues" option to the Issues Visibility list for the Roles/Permissions page would be awesome!
#38 Updated by Alex Petty over 4 years ago
We should add the functionality given by plugin "Redmine Tracker Control" (which allows for specific roles to only be able to create issues of tracker types for which the role has been given permission).
It would be great if this feature could be part of the Redmine 3.0.4 release since the "Redmine Tracker Control" plugin no longer works in 3.x
This would truly be a GREAT and VALUABLE feature for Redmine's overall flexibility in configuration, and would be hugely appreciate by many!!
#42 Updated by Thorsten Jäger over 4 years ago
In our case i want Profession-Service and Project-Managers in a Project - but only allow them to certain Trackers. They should not see other Trackers like "Bugs" "Features" "Escalations" etc.
The other case is Business-Partners. It would be very important of course to NOT let them see/work on internal Trackers in the same Project as they may contain internal Information.
In our case it also would be appreciated if i still could relate an issue (like "depends on").
Example: PJ-Mgr has R/W Access to Tracker "Task" but not other Trackers (like Bugs). It would be appreciated if the Developer-Role can have a "BUG" (Tracker) and set the relation to an issue in the "Task" Tracker - so the PJ-Mgr sees a dependency to that Bug in his "Task"-issue - but would not be able to move into that Bug-issue.
#44 Updated by Anton Titkov about 4 years ago
Anton Titkov wrote:
Please check a plugin http://www.redmine.org/plugins/tracker_hider and share your thoughts. Thanks!
Has enybody tested the plugin?
It allows to hide issues under selected tracker for roles/users within a project. It solves the subject partly as i see.
It would be nice to get some feeback from you!
#45 Updated by Jean-Philippe Lang over 3 years ago
- Status changed from New to Closed
- Target version set to 3.3.0
- Resolution set to Fixed
3.3.0 will support tracker based permissions for issue tracking. You will be able to limit the trackers for which a role is allowed to view, create, edit or delete issues.
#47 Updated by Shane Coronado over 2 years ago
- File create_tickets_by_copy.jpg added
- File create_tickets_by_copy2.jpg added
- File create_tickets_by_copy3.jpg added
- File create_tickets_by_copy4.jpg added
Not sure if intended: We use the permission settings for our roles. However, our Developer role is able to create an issue that the role does not have permission to create. This was done by Copying said issue and not changing the Tracker field. By leaving the Tracker field blank, the user is able to create an issue that bypasses the role's permissions.
#49 Updated by Darwin Pou about 1 year ago
How could I restrict access to a group of issues by user-role, tracker and state in workflow?
Role 2 can only view issues for workflow statuses: "Level 2" or "Level 3".
Role 3 can only view issues for workflow status: "Level 3".
Any: Could be viewed by "Role 1".
By now I have to limit readonly access to fields for specific status and role; but when I create a new status I have to modify all roles for that new status.