MantisBT

View Issue Details Jump to Notes ] Wiki ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003444mantisbtfeaturepublic2003-12-03 03:442014-04-22 07:57
ReporterTomWalter 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003444: Add user groups to streamline user management
DescriptionIt would be nice to have user groups, to which Access levels and Projects could be assigned, rather than assigning those things individually. For example in the case where you are tracking several projects from different clients, and each client has multiple users, and you want to be able to easily assign all the users from that client to the one project.
Tagsusergroups
Attached Filesdiff file icon diff_from_RELEASE_0_18_3_20040512.diff [^] (62,093 bytes) 2004-05-26 14:12 [Show Content]
zip file icon group_new_files.zip [^] (13,881 bytes) 2004-05-26 14:13
? file icon group_tables.sql [^] (1,080 bytes) 2004-05-26 14:13
zip file icon usergroups_diff_from_0_19_CVS_20040529.zip [^] (29,830 bytes) 2004-09-05 18:03
pdf file icon Creating groups in Mantis.pdf [^] (92,496 bytes) 2009-10-09 04:55

- Relationships
has duplicate 0007752closedgiallu User groups 
has duplicate 0011003closeddhx User groups for easy managing 
has duplicate 0011867closedatrol User Groups / Custom User Fields 
has duplicate 0007614closeddregad Better user accounts administration should be implemented (to support the administration of large group of users). 
related to 0002342closedgrangeway Create groups and locations for users to belong to 
related to 0012390new Feature request: User inheritance, similar to current category inheritance 
child of 0005381new more flexible group/role/profile/permission management 

-  Notes
User avatar (0005532)
lauploix (reporter)
2004-05-18 06:57

I agree. We have 15+ projects, and mainly 5+ user groups (sales, programmers, consulting, ...).

It would be so nice to be able to manage the rights at group level... and just add a user to a group when a new user arrives.
User avatar (0005574)
dwoods (reporter)
2004-05-24 13:08

I have implented something similar in some customizations a while ago. We have a number of distibutors of our product, and it's not always desirable for them to see ongoing issues with other distibutors (at least in management's eyes).

Basically, each bug has "group view list" associated with it. Only users in those groups can see the bug (it gets filtered out of the view_all pages as well). There is a new [Manage Groups] link to a new page in the Manage screen.

I made these changes based on 0.18.0a4, and am just in the process of porting my changes to 0.18.3. I could post it here when I'm finished if anyone's interested.
User avatar (0005580)
lauploix (reporter)
2004-05-25 01:59

Hi dwoods, I think this is also interesting to have a 'per bug' right management sometimes. In fact, I sometimes want to enable a specific user to view/update/... a bug that he has no right on.

Pb is I usually have sg like 150+ open issues, in 15+ different projects, with 100+ users in 5+ user groups. Mantis is really great for that. But that means that I cannot manage all rights on a per bug basic.

What would be so _great_ would be : once I have a new user, I just put him in several "groups" and he gets all the update/view/manage/... rights that the groups have.

But this is no contradiction with a more specific 'per user' or 'per bug' user rights management for specific purposes.
User avatar (0005583)
nuclearspike (reporter)
2004-05-25 10:23

in a somewhat related note, also have the auto-assignment of new issues be able to go to a user group/role. A customer enters a new problem, it first should get assigned to the triage group who verifies the bug before it gets assigned to the developer who works on that category. If it first goes to one person, that person is sometimes gone for weeks on the road and other people need to handle the triage. Our current solution is sort of hackish. We create a "Triage" user, have things assigned to them, then the triage group just checks for things assigned to that user, rather than to themselves. this, however, means that all new bugs go there and we cannot use the category auto-assignments for the actual developer. Auto-assignments may be best on a per-status level. New -> Triage, Confirmed -> Manager of the project or may go directly to the developer of that category. That's getting more into workflows... which is a separate request entirely. :D
User avatar (0005594)
dwoods (reporter)
2004-05-26 14:31
edited on: 2004-05-26 14:32

I've attached a diff from 0.18.3, as well as all new files in a .zip (diff includes new files) and an sql file to create new tables.

As it is right now, it doesn't actually filter out the issues in the view_all_page according to the group 'view list'. I wanted to change how i was doing this before I add it in.
Basically it went something like:

for each bug passed though all other filters
   get the group_view_list for that bug
   for each group
      if current_user is in group
         show bug
if current_user is reporter
   show bug


Also, the only way to add/remove groups to an issue is in the bug_view_advanced_page, which is clearly the wrong place. It should be in the bug_advanced_update_page.
Also I would like to add the ability to add a group to multiple bugs at the same time (via the checkboxes).

Also each user should have a 'default' group, that get added to the view list automatically when they submit new issue.

Still working on it.. :)

edited on: 05-26-04 14:32
User avatar (0007363)
nuclearspike (reporter)
2004-09-01 13:34

this is nice, but it adds groups to be able to see individual bugs, is there a way an entire group can be associated with a project?
User avatar (0007448)
dwoods (reporter)
2004-09-05 18:03

I have updated the patch since my posting, but forgot to update the post.
It's now diff'd from the latest from HEAD as of about a 2 months ago.

My company also wanted me to make additional modifications to allow 'projects' in addition to 'issues' (where are project is actually just another issue, only originating from within the company for one of our developers to handle). And the projects as they are now I have changed to 'products'.

Anyway, the patch I'm including has these changes in there as well. I apologize for this, but hope this at least some of the code I have written may be of some use. The user group stuff is fairly self-contained.


The user groups are only used right now for implementing an 'access-list' on a per-issue basis, as mentioned in a previous note, but it would also be nice if an issue could be assigned to a group of users. I think the basic framework is there...

I also attempted to add to the upgrade scripts to create the new tables. They seemed to work for me okay.
User avatar (0021906)
djcarr (reporter)
2009-05-24 23:31
edited on: 2009-05-24 23:35

With 100+ projects and 100+ users this is an area where the administration workload starts to become difficult. Being able to assign roles (or "user groups") to projects and then giving users one or several roles, would really bring Mantis into the realm of corporate applications.

Could others desiring this feature please also put a little encouragement in.. thank you :)

User avatar (0021931)
tk (reporter)
2009-05-27 01:35

Just for comment:

As a partial workaround, I implemented "assignment groups" by creating fake users which have a mailing list as email destination. The mailing list contains all people in that group.
In that way I can assign issues to groups of people. Now since the group members are all of level developer (otherwise assignment of an issue to them would make no sense) the actual user-in-charge can assign the issue to himself as soon as he starts working on it.
User avatar (0022027)
djcarr (reporter)
2009-06-01 19:08
edited on: 2009-06-01 19:15

Thanks for the input 'tk' - perhaps the scenario you are talking about is covered by 0000955 or 0006644? While I can see how that may be useful it is still somewhat different to this issue which is for a users-roles-privileges engine.

User avatar (0023105)
sveyret (reporter)
2009-10-09 04:57

Hi, I have made specifications about what I think could solve all the problems (see attached PDF file). Can you tell me your opinion about it? I hope I will find time to work on that issue soon.

Thank you.
User avatar (0023199)
sveyret (reporter)
2009-10-15 04:59

Specifications are now added to the Wiki page so everyone can work on it…
User avatar (0027115)
andy778 (reporter)
2010-10-22 02:31

Any idea when this will be developed and how much sponsoring would this require to get this done?
User avatar (0028016)
tiliarou (reporter)
2011-01-20 08:18

I'm very interested by this feature ! Adding group management to Mantis would make it so much better !
Is someone still working on this issue ? Does he need more sponsoring ?
User avatar (0028022)
djcarr (reporter)
2011-01-20 17:53
edited on: 2011-01-20 17:58

The specs in the wiki are very detailed but represent a very large amount of work. I am not sure why the login authentication code needs to be modified.

A simpler approach to address the original request:

- New table 'mantis_role_table' with fields: role_id, name, access_level
- New table 'mantis_project_role_table' with fields: project_id, role_id, access_level
- New table 'mantis_user_role_table' with fields: user_id, role_id
- Change all access level lookups in code to include these tables as well
- Use the highest access level found for that user and project

This is a relatively straightforward change that will provide big benefits to administrators and doesn't require migration of existing data to a new structure.

User avatar (0028101)
sveyret (reporter)
2011-01-27 03:28

I stopped working on this feature after a very big code loss at a time I was still trying to make git working… :-(
I will have no time to restart this job for the moment.
There are Mantis developpers currently working to re-write Mantis using the Zend framework. As Zend framework has got an easy way to manage access controls, this will probably be a good occasion to include group management.
User avatar (0029464)
andy778 (reporter)
2011-08-11 11:51

What is the current plan with this?
User avatar (0029467)
cas (reporter)
2011-08-12 03:00

Perhaps it will show up in a later version but so far there is little feedback on this. There are a few smaller patches around to group users and/or assiging sub tasks within one issue. if thos are usable for you, very much depends on your requirements
User avatar (0029470)
andy778 (reporter)
2011-08-12 11:26

We have over 300 mantis users and over 100 projects and the projects are private so what we would like is to add users to groups alias and groups should then be added under each project. Also ldap/AD authentication is needed. Sponsoring is also possible to arrange if needed.
User avatar (0032842)
cas (reporter)
2012-09-14 02:02

Now creating a plugin that will allow users to be connected to multiple groups (which can be defined seperately).
My tasks plugin will allow to assign tasks to one of those groups. Each task can then be handled by anyone from that group. System will register which user in the end will complete the task.
Although not full group management, it will be enough for our purposes.
User avatar (0032872)
cas (reporter)
2012-09-19 01:45

For those interested, the plugin is available and released together with an updated version of the Tasks plugin.
See:
http://www.mantisbt.org/bugs/view.php?id=14716 [^]
User avatar (0039801)
HeikoSL (reporter)
2014-04-01 04:37

I have created another plugin for usergroups:
This plugin can be used to create groups of users in your mantis bugtracker. You may use nested groups and you can decide if groups can handle a bug. Notifications will be send to all group members.

The plugin creates one table that holds the groups with their members. But: To use this plugin you must edit some core functions!

See: https://github.com/langerheiko/ManageUsergroups [^]
User avatar (0040114)
hincelin (reporter)
2014-04-17 08:42

@ HeikoSL,
Thanks for this new plungin.
Can it be used with 1.2.17 ?
Sincerely
User avatar (0040132)
HeikoSL (reporter)
2014-04-22 07:57

I am running it on 1.2.14, but I tested it with 1.2.17. It's working.

- Issue History
Date Modified Username Field Change
2003-12-03 03:44 TomWalter New Issue
2004-05-18 06:57 lauploix Note Added: 0005532
2004-05-24 13:08 dwoods Note Added: 0005574
2004-05-25 01:59 lauploix Note Added: 0005580
2004-05-25 10:23 nuclearspike Note Added: 0005583
2004-05-26 14:12 dwoods File Added: diff_from_RELEASE_0_18_3_20040512.diff
2004-05-26 14:13 dwoods File Added: group_new_files.zip
2004-05-26 14:13 dwoods File Added: group_tables.sql
2004-05-26 14:31 dwoods Note Added: 0005594
2004-05-26 14:32 dwoods Note Edited: 0005594
2004-07-24 09:05 grangeway Relationship added related to 0002342
2004-09-01 13:34 nuclearspike Note Added: 0007363
2004-09-05 16:10 grangeway Assigned To => grangeway
2004-09-05 18:03 dwoods File Added: usergroups_diff_from_0_19_CVS_20040529.zip
2004-09-05 18:03 dwoods Note Added: 0007448
2005-03-23 18:05 vwegert Relationship added child of 0005381
2008-07-16 14:12 grangeway Status new => assigned
2008-08-07 04:17 giallu Relationship added has duplicate 0007752
2009-05-24 23:25 djcarr Sponsorship Added djcarr: US$ 50
2009-05-24 23:25 djcarr Sponsorship Total 0 => 50
2009-05-24 23:31 djcarr Note Added: 0021906
2009-05-24 23:35 djcarr Note Edited: 0021906 View Revisions
2009-05-27 01:35 tk Note Added: 0021931
2009-06-01 19:09 djcarr Note Added: 0022027
2009-06-01 19:11 djcarr Note Edited: 0022027 View Revisions
2009-06-01 19:15 djcarr Note Edited: 0022027 View Revisions
2009-10-06 03:02 dhx Relationship added has duplicate 0011003
2009-10-09 04:55 sveyret File Added: Creating groups in Mantis.pdf
2009-10-09 04:57 sveyret Note Added: 0023105
2009-10-15 04:59 sveyret Note Added: 0023199
2010-10-22 02:31 andy778 Note Added: 0027115
2011-01-20 08:18 tiliarou Note Added: 0028016
2011-01-20 17:53 djcarr Note Added: 0028022
2011-01-20 17:54 djcarr Note Edited: 0028022 View Revisions
2011-01-20 17:58 djcarr Note Edited: 0028022 View Revisions
2011-01-27 03:28 sveyret Note Added: 0028101
2011-08-11 11:51 andy778 Note Added: 0029464
2011-08-12 03:00 cas Note Added: 0029467
2011-08-12 11:26 andy778 Note Added: 0029470
2011-08-14 08:55 atrol Relationship added has duplicate 0011867
2011-11-28 12:11 dregad Relationship added related to 0012390
2012-02-28 11:29 dregad Relationship added has duplicate 0007614
2012-09-12 11:03 dregad Assigned To grangeway =>
2012-09-12 11:03 dregad Status assigned => confirmed
2012-09-14 02:02 cas Note Added: 0032842
2012-09-19 01:45 cas Note Added: 0032872
2012-09-20 05:49 cas Tag Attached: usergroups
2014-04-01 04:37 HeikoSL Note Added: 0039801
2014-04-17 08:42 hincelin Note Added: 0040114
2014-04-22 07:57 HeikoSL Note Added: 0040132


MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.1371 seconds.
memory usage: 3,391 KB
Powered by Mantis Bugtracker