View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007614||mantisbt||administration||public||2006-11-26 11:10||2012-03-04 02:08|
|Target Version||Fixed in Version|
|Summary||0007614: Better user accounts administration should be implemented (to support the administration of large group of users).|
Currently, our Mantis installation includes 87 accounts.
|Steps To Reproduce|
Please contact me if you need more info about this feature, we (Zend Technologies) are willing to pay a developer to implement this feature.
|Tags||No tags attached.|
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:
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.
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.
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.
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.
Follow up on djcarr's "tangential suggestion" in 0011975
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;
|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|