Feature #285

Tracker role-based permissioning

Added by Alessio Spadaro over 10 years ago. Updated 17 days ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Issues workflow
Target version:3.3.0
Resolution:Fixed

Description

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.

Regards,
Alessio

Issues Visibility.JPG (28 KB) Lázaro Hermoso, 2013-10-22 12:05

create_tickets_by_copy.jpg (29.7 KB) Shane Coronado, 2017-05-08 21:21

create_tickets_by_copy2.jpg (24.6 KB) Shane Coronado, 2017-05-08 21:25

create_tickets_by_copy3.jpg (20.2 KB) Shane Coronado, 2017-05-08 21:26

create_tickets_by_copy4.jpg (30.4 KB) Shane Coronado, 2017-05-08 21:26


Related issues

Related to Redmine - Feature #973: Assign different status sets and workflows for separate p... New 2008-04-02
Related to Redmine - Feature #1462: Access control to trackers by user roles/profiles New 2008-06-16
Related to Redmine - Feature #7839: Limit trackers for new issue to certain roles Closed 2011-03-11
Related to Redmine - Feature #8570: Extension of the tracker-role relation New 2011-06-09
Related to Redmine - Feature #3077: Customer Feedback System New 2009-03-30
Related to Redmine - Feature #8488: Create an 'Involve' mechanism to private issues New
Related to Redmine - Defect #23969: Edit/delete links displayed on issue even if project is c... Closed
Duplicated by Redmine - Feature #3726: Trackers per Role Closed 2009-08-10
Duplicated by Redmine - Feature #2791: Allow trackers to be visible by specific roles only Closed 2009-02-20
Duplicated by Redmine - Feature #2240: Ability to constrain tracker by role Closed 2008-11-27

Associated revisions

Revision 15465
Added by Jean-Philippe Lang about 1 year ago

Adds issue visibility by role/tracker (#285).

Revision 15466
Added by Jean-Philippe Lang about 1 year ago

Adds permission to edit and delete issues by role/tracker (#285).

Revision 15478
Added by Jean-Philippe Lang about 1 year ago

Merged 15430, 15464 to 15469, 15475, 15476 (#285, #7839).

Revision 15540
Added by Jean-Philippe Lang about 1 year ago

Limits the tracker list in filters and issue counts (#285).

History

#1 Updated by Chris Leonard almost 10 years ago

I spent a little more time researching this and thinking through
it.

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).

Thanks,
Chris

#2 Updated by Thomas Lecavelier almost 10 years ago

This could be a prioritary feature, since there's maybe the last
thing that prevent a mass adoption of redmine by my client.

A non-technical view of issues will be a great help for manager,
with some statistics to please the most of managers.

#3 Updated by Chris Leonard almost 10 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.
Chris

#4 Updated by Thomas Lecavelier over 10 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):
Internal/External.

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 10 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 9 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

regards

gabriel

#7 Updated by Oyku Gencay about 9 years ago

Hi folks,

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?

Thanks.

#8 Updated by gabriel scolan about 9 years ago

That will be great to have this in version 0.8 ! I'm eager to see it as a feature of Redmine !

#9 Updated by gabriel scolan almost 9 years ago

Hi Oyku,

Did you find your way to share your code ? I really like to see this. May be you could attached it to this ticket, identifying the baseline (version 0.7.1 for example) with quick instructions for installing it.

many thanks
gabriel

#10 Updated by Guilherme Schneider over 8 years ago

I'm interested in this too.

#11 Updated by Mélanie Gault over 7 years ago

is there any more informations about this feature ?
I am interested too...

#12 Updated by Dario Laera over 7 years ago

+1 for me

#13 Updated by Etienne Massip about 6 years ago

  • Category set to Issues workflow

#14 Updated by Julien Breux almost 6 years ago

Up, up, up and up :-)

Please, this is the only missing features to allow customers to enter bugs properly.

#15 Updated by Ross Hendrickson almost 6 years ago

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.

#16 Updated by James Ang over 5 years ago

+1

#17 Updated by Mariano crivello about 5 years ago

+10 :D

#18 Updated by Sam Warns almost 5 years ago

+1

#19 Updated by Florent Fievez over 4 years ago

+1

#20 Updated by Anthony HERBÉ over 4 years ago

  • Assignee set to Jean-Philippe Lang

+1

"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 4 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.

#22 Updated by Dipan Mehta over 4 years ago

The issue #3077 will be solved by this one.

#23 Updated by François Pouilloux almost 4 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.

+1

Same need here, reporters can create bugs but features are in the hands of the development team.

#24 Updated by Terence Mill almost 4 years ago

+1

#25 Updated by Anthony HERBÉ almost 4 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.

#26 Updated by Daniel Felix almost 4 years ago

Maybe I missed something, but this is already possible, doesn't it? You can define a role which enables each user just to see his own issues.

Do you mean this feature with this request or something different?

#27 Updated by Ty You almost 4 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.

#28 Updated by Ty You almost 4 years ago

...but I went to GitHub and pulled version 1.0.8 instead of the 1.0.5 listed here and it worked! Nice, this should be made more obvious - thanks!

#29 Updated by Lázaro Hermoso over 3 years ago

+1
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:
  1. All issues
  2. All non private issues
  3. Issues created by or assigned to the user
  4. 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 over 3 years ago

+1
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 over 3 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:

https://github.com/jijeshmohan/redmine_track_control/zipball/redmine2

I still believe this should be included in the core pack.

#32 Updated by Sam He over 3 years ago

+1
I do hope this permission control can be included in the core pack asap.

#33 Updated by Monica Kochofar about 3 years ago

+1

It would certainly make the experience for our users a whole lot smoother.

#34 Updated by Toshi MARUYAMA almost 3 years ago

  • Related to Feature #8488: Create an 'Involve' mechanism to private issues added

#35 Updated by Maxim Krušina over 2 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
And our internal trackers (Features, Bugs)
  • Clients (group) - not visible
  • Project Managers (group) - visible
  • Developers (group) - visible

#36 Updated by Artem Tovbin over 2 years ago

+1.
We need to get view access to Customer to some tracker.

#37 Updated by mike B over 2 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 almost 2 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!!

#39 Updated by Ricard F almost 2 years ago

I think too it should be added nativelly!!

#40 Updated by Michal Kowalski almost 2 years ago

Yes please.

#41 Updated by Joe Zuber almost 2 years ago

We too have a need for this functionality. We don't want to move some users to a seperate project but we do want to restrict them to only creating bug tickets. I would add to this request that the role based rights should also be tied to the project.

#42 Updated by Thorsten Jäger almost 2 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.

#43 Updated by Anton Titkov over 1 year ago

Hello everyone!
Please check a plugin http://www.redmine.org/plugins/tracker_hider and share your thoughts. Thanks!

#44 Updated by Anton Titkov over 1 year ago

Anton Titkov wrote:

Hello everyone!
Please check a plugin http://www.redmine.org/plugins/tracker_hider and share your thoughts. Thanks!

Hello guys!
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!
Thanks!

#45 Updated by Jean-Philippe Lang about 1 year 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.

#46 Updated by Jean-Philippe Lang 9 months ago

  • Related to Defect #23969: Edit/delete links displayed on issue even if project is closed added

#47 Updated by Shane Coronado about 1 month ago

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.

#48 Updated by Toshi MARUYAMA 17 days ago

Shane Coronado wrote:

Not sure if intended:...

FTR: #25791.

Also available in: Atom PDF