View Issue Details

IDProjectCategoryView StatusLast Update
0007614mantisbtadministrationpublic2012-03-04 02:08
Reporterzend Assigned Todregad  
Status closedResolutionduplicate 
Summary0007614: Better user accounts administration should be implemented (to support the administration of large group of users).

Currently, our Mantis installation includes 87 accounts.
We also use Mantis to track issues for more then 30 different projects.
As a defaults, each user account gets the "Reporter" access level when it is created. after the creation of the account, the user sets a meeting with our Mantis administrator who is giving him different access levels for different projects (the administrator is actually assigning him to different projects with different access levels).
The problem is that this is extremely uncomfortable to maintain 87 user accounts with so many different projects.
What we need is a better way to handle groups of user accounts with the same access level to the same projects (see the below section for a suggested case study).

Steps To Reproduce


  1. We have one group that should be called testers. whenever a user account is "added" to this user group, he will have automatically all the access level that this group is having.
    We will have to have the ability to add more and more groups like that (i.e Testers - Product1, Testers Product 2, Testers Product 3, Managers Product 4, Developers Product 5 etc.).
  2. it should be possible to add groups to a specific project from the manage project page. after a group is added to a project all of its users are automatically added to this project.
  3. after removing a group from a project, all of this group users should be immediately and automatically removed from this project.
Additional Information

Please contact me if you need more info about this feature, we (Zend Technologies) are willing to pay a developer to implement this feature.

Amit Roseberger

TagsNo tags attached.


duplicate of 0003444 confirmed Add user groups to streamline user management 
related to 0011975 new New feature: Request Access Level 




2007-03-29 20:11

reporter   ~0014281

Last edited: 2007-03-29 20:12

It seems to me that this bug could potentially kill several birds with one stone.

If the back-end solution to this bug was thoughtfully designed, it could provide a useful framework for resolving other similar bugs such as bug 0006758: Access level for users authenticated via LDAP determined by LDAP group membership.

Bug 0006758 was filed with access levels specifically in mind, but now I'm envisioning a more general and robust solution:

  • The 'groups' layer in Mantis could be made provider-neutral (in the same way as the authentication mechanism).

  • 'Groups' and 'group membership' could then be defined internally (i.e. in the local database) or externally (using, for example, LDAP or Active Directory).

  • 'Group management' (defining which groups have which properties and are linked to which projects) would then be done internally by Mantis.

I'd be happy to help out in general on this bug, and specifically on the LDAP side as that is of particular interest here.



2009-08-04 02:56

reporter   ~0022652

I like the sound of this, and would especially like to see 'groups' decoupled from LDAP. The Mantis administrator doesn't necessarily have any control over the LDAP server, and would need the ability to manage 'groups' independently of that.



2009-08-04 07:31

reporter   ~0022656

Better administration of groups of users would be beneficial to us to. someone as trivial as escalating a user from reporter to developer in 50 projects is a very time consuming and labour intensive job!

Also a 'copy from' for users? So you can copy a configuration from another user would be very useful.



2009-10-07 20:01

reporter   ~0023095

Last edited: 2009-10-07 20:03

View 2 revisions

A tangential suggestion which fits under the rather broad Summary of this issue but feel free to split it off to another issue:

A mechanism by which users can request an access level on a project. Mantis then emails the managers on the project, containing two links; to accept or reject the request. The landing page will indicate if another person already actioned the request. If there are no managers, no action has been taken within a configured period of hours, or the user opts to escalate it themselves (eg. they know the usual manager is away) then the request is escalated to the administrator.

As Mantis deployments grow from 10 to 100 projects, users still tend to "ask the administrator", rather than one of the project's managers. In addition, new users don't know who to contact regarding project access, and the administrator has to go and ask about each user's intended projects after seeing the "New Account" email notification.

So a feature like this would really help to decentralize and automate the running of Mantis.



2012-02-28 11:32

developer   ~0031345

Follow up on djcarr's "tangential suggestion" in 0011975



2012-02-28 13:40

reporter   ~0031348

I have used a little insert query to clone users, (Yes a guy on this would perhaps be suitable)

Here 351 is the user to clone to and 135 is id from (There one get quite simply from the manage users page)

INSERT IGNORE INTO mantis_project_user_list_table (user_id,project_id,access_level) SELECT 351, project_id, access_level FROM mantis_project_user_list_table WHERE user_id=135;

Issue History

Date Modified Username Field Change
2006-11-26 11:10 zend New Issue
2007-03-25 01:55 vboctor Status new => assigned
2007-03-25 01:55 vboctor Assigned To => vboctor
2007-03-29 20:11 ape Note Added: 0014281
2007-03-29 20:12 ape Note Edited: 0014281
2009-07-28 09:17 vboctor Assigned To vboctor =>
2009-07-28 09:17 vboctor Status assigned => acknowledged
2009-08-04 02:56 djcarr Note Added: 0022652
2009-08-04 07:31 jonathh Note Added: 0022656
2009-10-07 20:01 djcarr Note Added: 0023095
2009-10-07 20:03 djcarr Note Edited: 0023095 View Revisions
2009-10-07 20:11 djcarr Sponsorship Added djcarr: US$ 25
2009-10-07 20:11 djcarr Sponsorship Total 0 => 25
2012-02-28 11:29 dregad Relationship added duplicate of 0003444
2012-02-28 11:29 dregad Status acknowledged => resolved
2012-02-28 11:29 dregad Resolution open => duplicate
2012-02-28 11:29 dregad Assigned To => dregad
2012-02-28 11:32 dregad Relationship added related to 0011975
2012-02-28 11:32 dregad Note Added: 0031345
2012-02-28 13:40 andy778 Note Added: 0031348
2012-03-04 02:08 vboctor Status resolved => closed