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
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
That will be great to have this in version version:"0.8" ! I'm eager to see it as a feature of Redmine !
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
I'm interested in this too.
--------------------------------------------------------------------------------
is there any more informations about this feature ?
I am interested too...
--------------------------------------------------------------------------------
+1 for me
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Up, up, up and up :-)

Please, this is the only missing features to allow customers to enter bugs properly.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
+10 :D
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
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":http://www.redmine.org/plugins/redmine_track_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.
--------------------------------------------------------------------------------
The issue #3077 will be solved by this one.
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
Dipan Mehta wrote:
> However there is a plugin called "Redmine Tracker Control":http://www.redmine.org/plugins/redmine_track_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.

--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
...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!
--------------------------------------------------------------------------------
+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:
# 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... :(
--------------------------------------------------------------------------------
+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...

--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
+1
I do hope this permission control can be included in the core pack asap.
--------------------------------------------------------------------------------
+1

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

--------------------------------------------------------------------------------
+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
--------------------------------------------------------------------------------
+1.
We need to get view access to Customer to some tracker.
--------------------------------------------------------------------------------
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!

--------------------------------------------------------------------------------
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!!
--------------------------------------------------------------------------------
I think too it should be added nativelly!!
--------------------------------------------------------------------------------
Yes please.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------
Hello everyone!
Please check a plugin http://www.redmine.org/plugins/tracker_hider and share your thoughts. Thanks!
--------------------------------------------------------------------------------
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!

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

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Shane Coronado wrote:
> Not sure if intended:...

FTR: #25791.
--------------------------------------------------------------------------------
How could I restrict access to a group of issues by user-role, tracker and state in workflow?
For example;
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.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,New,973,Assign different status sets and workflows for separate projects
relates,New,1462,Access control to trackers by user roles/profiles
relates,Closed,7839,Limit trackers for new issue to certain roles
relates,Closed,8570,Extension of the tracker-role relation
relates,New,3077,Customer Feedback System
relates,New,8488,Create an 'Involve' mechanism to private issues
relates,Closed,23969,Edit/delete links displayed on issue even if project is closed
relates,Closed,30121,Projects API should not return invisible trackers
duplicates,Closed,3726,Trackers per Role
duplicates,Closed,2791,Allow trackers to be visible by specific roles only
duplicates,Closed,2240,Ability to constrain tracker by role
duplicates,Closed,16309,Add a concept of role-based permission to trackers
precedes,New,34570,Misleading workflow/permission issue
precedes,New,34284,In Role edit view the per tracker table only shows up when "View Issues" permission is selected