0007614: Better user accounts administration should be implemented (to support the administration of large group of users). - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0007614	mantisbt	administration	public	2006-11-26 11:10	2012-03-04 02:08

Reporter	zend	Assigned To	dregad
Priority	normal	Severity	feature	Reproducibility	always
Status	closed	Resolution	duplicate

Summary	0007614: Better user accounts administration should be implemented (to support the administration of large group of users).
Description	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	I.e. 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.). 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. 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 amit@zend.com
Tags	No tags attached.

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

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

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

djcarr 2009-10-07 20:01 reporter ~0023095 Last edited: 2009-10-07 20:03	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.

dregad 2012-02-28 11:32 developer ~0031345	Follow up on djcarr's "tangential suggestion" in 0011975

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