View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005151||mantisbt||administration||public||2005-01-24 20:53||2019-06-14 06:40|
|Target Version||2.20.0||Fixed in Version||2.20.0|
|Summary||0005151: Can't update user's project-specific access level|
The problem is when I want to change some user's account level (e.g. from updater to manager) I first have to delete the user from the project and then add the user with the other level of permissions. It's not a very big problem but I think it is worth of modifing since it would be simplifing administrator's job and I think it's not difficult to modify this feature.
|Tags||No tags attached.|
|has duplicate||0015278||closed||dregad||Edit access rights when editing a project|
|has duplicate||0009717||closed||managing users to allow edit of role/perms instead of remove and re-add|
|has duplicate||0007023||closed||Editing users in a private project is awkward|
|related to||0025722||closed||cproensa||Wrong access_level settings when updating rights in the project admin page|
Can you retest this in a later version of Mantis? I believe that you can change the user's access level through the Manage Users page.
I believe the original question was about a user that has been added to a project, not a user account access level as your note suggests.
With 1.0.0a3, I can get to Manage Users only if I am an administrator, and once there I can edit the user's account access level, but when I add them to projects they have another access level which can only be removed, not edited.
Similarly, if I am managing a project as a manager, I can add users using Manage Projects but I can only remove the added users and add them again. I cannot edit their access level without removing them.
This actually is a minor concurrency issue. If you are forced to remove the user for a short time, and the user is actively working on issues, they may lose access temporarily and complain that mantis was unreliable or had a bug (which of course they can no longer reproduce).
You are correct. We need an "Update" button beside the "remove" one.
I've had the same problem. And I've build a plugin that replaces the access level string by a dropdown menu to change the access level. On change an ajax call sets the new value in database (it deletes user and set the new access level).
You can find my plugin on github: https://github.com/langerheiko/AdminsToolbox
MantisBT: master e5049441
Committer: dregad Details Diff
|Improve project users manage page
Improve Project edit page, user management.
Add js functionality based in list.js with pagination, sorting and
Allow the staging of changes for modifications in access level and user
removal, within the user list.
Changes are applied as a whole and can be reviewed and validated after
|mod - core/prepare_api.php||Diff File|
|mod - core/project_api.php||Diff File|
|mod - css/ace-mantis.css||Diff File|
|mod - css/default.css||Diff File|
|add - js/manage_proj_edit_page.js||Diff File|
|mod - lang/strings_english.txt||Diff File|
|mod - manage_proj_edit_page.php||Diff File|
|add - manage_proj_user_update.php||Diff File|
MantisBT: master ef311984
2019-03-08 17:15:05Details Diff
|Follow-up fixes for improved manage project users page
- Adjust column width
- Fix js error on empty section
- Fix misplaced div
Pull request https://github.com/mantisbt/mantisbt/pull/1474
|mod - js/manage_proj_edit_page.js||Diff File|
|mod - manage_proj_edit_page.php||Diff File|
MantisBT: master 8eeb25ff
2019-04-16 11:27:49Details Diff
|Add optional $p_link param to print_user()
In 2.20.0, prepare_user_name() received a new optional parameter to
allow username to be printed as-is without making it an HTML link (see
commit e504944145090f74a16f11688ec84238243aa2d8, issue 0005151).
It makes sense that this capability is extended to print_user() API.
|mod - core/print_api.php||Diff File|
|2005-01-24 20:53||staszkiewicz||New Issue|
|2005-06-14 17:53||thraxisp||Note Added: 0010525|
|2005-06-14 17:53||thraxisp||Status||new => feedback|
|2005-07-13 08:07||toddpw||Note Added: 0010751|
|2005-07-13 17:22||thraxisp||Note Added: 0010763|
|2005-07-13 17:22||thraxisp||Status||feedback => confirmed|
|2012-12-12 03:18||dregad||Relationship added||has duplicate 0015278|
|2013-08-29 05:45||HeikoSL||Note Added: 0037949|
|2019-01-22 19:42||cproensa||Relationship added||has duplicate 0009717|
|2019-01-22 19:46||cproensa||Relationship added||has duplicate 0007023|
|2019-01-23 18:04||cproensa||Assigned To||=> cproensa|
|2019-01-23 18:04||cproensa||Status||confirmed => assigned|
|2019-01-23 18:05||cproensa||Note Added: 0061287|
|2019-03-02 19:13||dregad||Changeset attached||=> MantisBT master e5049441|
|2019-03-02 19:13||cproensa||Status||assigned => resolved|
|2019-03-02 19:13||cproensa||Resolution||open => fixed|
|2019-03-02 19:13||cproensa||Fixed in Version||=> 2.20.0|
|2019-03-03 16:43||atrol||Target Version||=> 2.20.0|
|2019-03-08 17:22||dregad||Changeset attached||=> MantisBT master ef311984|
|2019-03-08 17:22||dregad||Assigned To||cproensa => dregad|
|2019-03-16 20:20||vboctor||Status||resolved => closed|
|2019-04-29 16:03||atrol||Relationship added||related to 0025722|
|2019-04-30 04:48||dregad||Summary||inconvenience while handling user's accounts => Can't update user's project-specific access level|
|2019-06-14 06:40||dregad||Changeset attached||=> MantisBT master 8eeb25ff|