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.

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

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

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

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'?

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.

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.