Redmine

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

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.

The issue #3077 will be solved by this one.