View Issue Details

IDProjectCategoryView StatusLast Update
0011975mantisbtfeaturepublic2015-10-30 05:02
Reporterdjcarr Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Product Version1.2.1 
Summary0011975: New feature: Request Access Level
Description

Once users register in Mantis there is no obvious mechanism for them to get the access levels they need for their projects. They cannot identify or contact the managers of each project from within Mantis. They are forced to communicate outside of Mantis and they seek out the Mantis administrator rather than the project managers. In addition, the approval process requires the administrator/manager to spend a minute of navigation and scrolling in Mantis. This administration cost increases as the number of projects and users increase.

The idea behind this new feature is that a user should be able to "Request Access Level" from within Mantis. They would select a new level and choose from a list of suitable managers to send the request to. Mantis will email the managers with the details of the request and include a link. Clicking the link will launch a Mantis form pre-populated with the requested level for the manager to confirm. The user will then receive an email notification about the new access level.

Additional Information

I am working on this solution and will provide some files soon. Do others think it would be a good feature to have in Mantis?

I am also not sure whether it should be a plugin. The feature itself is very self-contained but it will require a few links/buttons in places that don't currently have a plugin point, for example "Logged in as: username (<u>change access level</u>)"

Tagspatch

Relationships

related to 0007614 closeddregad Better user accounts administration should be implemented (to support the administration of large group of users). 

Activities

djcarr

djcarr

2010-06-03 21:51

reporter  

djcarr

djcarr

2010-06-03 22:00

reporter   ~0025691

Last edited: 2010-06-03 23:02

View 7 revisions

See attached file: request_access_level_v01.zip

I have designed this initial version in a way that it can be easily dropped into Mantis and removed again, for testing purposes.

Installation: Copy the 4 new php files to your Mantis v1.2.1 root directory. You can then either apply the provided patch to core/html.api (it just adds a link) or you can modify the url in your browser to visit account_access_level_page.php.

NOTE: You will need to use an account with less than manager level to access the page. You need to have email notifications enabled on the site.

Operation:

  1. Low level user on a project clicks the link to request a new level (see v01_request_link.png)

  2. User selects one or several managers and administrators. There is currently a constant in the code limiting them to no more than 3 selections, to prevent a storm of emails. (see v01_request_page.png - imagine that "developer" level and "docbrown" manager will be selected.)

  3. Mantis sends an email to these managers naming the user, their current level and their requested level, and containing a link like this:

    manage_proj_user_modify_page.php?project_id=83&user_id=112&access_level=55&alert_nochange=1
  4. Manager clicks the link in the email which loads the user access level change page (see v01_approval_page.png) pre-populated with the requested information.

  5. If another manager also clicks the link, the page will alert them: "Note: the user is already at this access level. Permission may have already been granted."

  6. Manager confirms the new access level for the user. If "Notify User" is checked, the user will receive an email alerting them to their new access level. This notification is taken from and works in the same way as the normal user account page.

  7. Manager is then redirected to an appropriate page to further review the user or the project settings.

These pages perform their own access authentication on the manager, so hash confirmations are not required. They are also designed with open parameters and using Mantis URL naming conventions so they can be re-used for general administration. For example manage_proj_edit_page.php could provide links to change a user's access level rather than having to remove them from the project and add them again.

djcarr

djcarr

2010-06-03 22:29

reporter  

v01_request_link.PNG (2,052 bytes)   
v01_request_link.PNG (2,052 bytes)   
djcarr

djcarr

2010-06-03 22:29

reporter  

v01_request_page.PNG (16,292 bytes)   
v01_request_page.PNG (16,292 bytes)   
djcarr

djcarr

2010-06-03 22:30

reporter  

v01_approval_page.PNG (12,990 bytes)   
v01_approval_page.PNG (12,990 bytes)   
djcarr

djcarr

2010-06-04 01:48

reporter   ~0025692

Last edited: 2010-06-04 02:06

View 3 revisions

Small bug in v01 denying access to non-global managers. Change manage_proj_user_modify_page.php:

access_ensure_global_level( config_get( 'manage_user_threshold' ) );
access_ensure_project_level( config_get( 'manage_project_threshold' ), $f_project_id );
access_ensure_project_level( config_get( 'project_user_threshold' ), $f_project_id );   

$f_project_id   = gpc_get_int( 'project_id' );
$f_user_id      = gpc_get_int('user_id');
$f_alert_nochange = gpc_get_bool('alert_nochange', false );

to:

$f_project_id   = gpc_get_int( 'project_id' );
$f_user_id      = gpc_get_int('user_id');
$f_alert_nochange = gpc_get_bool('alert_nochange', false );

access_ensure_project_level( config_get( 'manage_project_threshold' ), $f_project_id );
access_ensure_project_level( config_get( 'project_user_threshold' ), $f_project_id );
cas

cas

2010-06-04 06:20

reporter   ~0025696

This can be very helpfull, should actually make it into Core (1.2.2?)
Would expect also to see a Deny button though.

djcarr

djcarr

2010-06-06 19:04

reporter   ~0025715

Good suggestion cas thanks, I will add that into v02.

dhx

dhx

2010-06-07 07:53

reporter   ~0025724

Interesting idea. Good work so far on the patch. Thanks for the screenshots too!

I think it'd be a good idea to make it clearer which project the user is attempting to seek higher access to. It seems ambiguous from a user perspective whether they're seeking higher global access or higher project access (which project is also unclear).

I'm also a little hesitant about listing the account names of everyone who has permission to accept the request. Likewise with the listing of all higher access levels... perhaps some are meant to be 'secret' or 'internal'?

djcarr

djcarr

2010-06-08 04:17

reporter   ~0025752

Last edited: 2010-06-08 04:18

View 2 revisions

Thanks for the feedback dhx.

Both pages show the Project name in question - if the user is requesting higher access globally then "All Projects" would be shown.

You make a good point about displaying unwanted names. Perhaps a new config option that defaults to:

$g_project_user_approval_threshold_max = ADMIN;

If you wanted to hide admins you then set this to MANAGER, and because the minimum ($g_project_user_threshold) is also MANAGER, admins are not shown to the user making the request.

For "secret managers", an admin can create a SECRETMANAGER accesslevel above MANAGER but with the same rights, and they would also be excluded by these thresholds.

djcarr

djcarr

2010-07-02 00:37

reporter  

djcarr

djcarr

2010-07-02 00:37

reporter  

v02_request_page_named.PNG (8,744 bytes)   
v02_request_page_named.PNG (8,744 bytes)   
djcarr

djcarr

2010-07-02 00:37

reporter  

v02_request_page_unnamed.PNG (9,876 bytes)   
v02_request_page_unnamed.PNG (9,876 bytes)   
djcarr

djcarr

2010-07-02 01:59

reporter   ~0026014

Last edited: 2012-01-03 01:31

View 5 revisions

I've attached v02 of this feature to address most of the suggestions raised.

New zip: request_access_level_v02.zip (request_access_level_v01.zip is now obsolete)
New images: v02_request_page_named.PNG, v02_request_page_unnamed.PNG (v01_request_page.PNG is now obsolete)
Existing images: v01_request_link.PNG and v01_approval_page.PNG still apply.

Installation:

Extract request_access_level_v02.zip to your Mantis root directory, then either patch html_api.php to create the link or visit account_access_level_page.php directly in your browser.

Version 02 now contains four config options:

# Enable the 'Request Access Level' feature
$g_allow_request_access_level = ON;

# Upper threshold for people that can be sent an Access Level Request by a user.
$g_project_user_approval_threshold_max = MANAGER;

# A limit on the number of managers you can send an access level request to at one time.
$g_request_access_level_approvers_max = 3;

#Show the names of managers when requesting an access level
$g_show_manager_usernames = ON;

The request form now indicates whether the approvers have project or global rights. They are also sorted by these rights and then their name.

The request form can conceal the names of the approvers by setting $g_show_manager_usernames=OFF

Administrators are excluded by default but can be included by setting $g_project_user_approval_threshold_max=ADMINISTRATOR

The two new screenshots demonstrate various combinations of these config options.

The only suggestion I didn't address was the addition of a "Deny" button. I haven't found a nice way to implement it without database changes. I also find it can cause conflict in a team when one manager approves a request and another denies it, a lot depends on the sequence they act in. For now I think simple is best.

Issue History

Date Modified Username Field Change
2010-06-01 20:11 djcarr New Issue
2010-06-03 21:51 djcarr File Added: request_access_level_v01.zip
2010-06-03 22:00 djcarr Note Added: 0025691
2010-06-03 22:01 djcarr Note Edited: 0025691 View Revisions
2010-06-03 22:01 djcarr Note Edited: 0025691 View Revisions
2010-06-03 22:29 djcarr File Added: v01_request_link.PNG
2010-06-03 22:29 djcarr File Added: v01_request_page.PNG
2010-06-03 22:30 djcarr File Added: v01_approval_page.PNG
2010-06-03 22:44 djcarr Note Edited: 0025691 View Revisions
2010-06-03 22:47 djcarr Note Edited: 0025691 View Revisions
2010-06-03 23:01 djcarr Note Edited: 0025691 View Revisions
2010-06-03 23:02 djcarr Note Edited: 0025691 View Revisions
2010-06-04 01:48 djcarr Note Added: 0025692
2010-06-04 01:49 djcarr Note Edited: 0025692 View Revisions
2010-06-04 02:06 djcarr Note Edited: 0025692 View Revisions
2010-06-04 06:20 cas Note Added: 0025696
2010-06-06 19:04 djcarr Note Added: 0025715
2010-06-07 07:53 dhx Note Added: 0025724
2010-06-07 07:53 dhx Tag Attached: patch
2010-06-08 04:17 djcarr Note Added: 0025752
2010-06-08 04:18 djcarr Note Edited: 0025752 View Revisions
2010-07-02 00:37 djcarr File Added: request_access_level_v02.zip
2010-07-02 00:37 djcarr File Added: v02_request_page_named.PNG
2010-07-02 00:37 djcarr File Added: v02_request_page_unnamed.PNG
2010-07-02 01:59 djcarr Note Added: 0026014
2010-07-02 02:00 djcarr Note Edited: 0026014 View Revisions
2010-07-02 02:02 djcarr Note Edited: 0026014 View Revisions
2010-07-02 02:02 djcarr Note Edited: 0026014 View Revisions
2012-01-03 01:31 djcarr Note Edited: 0026014 View Revisions
2012-02-28 11:32 dregad Relationship added related to 0007614