View Issue Details

IDProjectCategoryView StatusLast Update
0005239mantisbtfeaturepublic2017-11-02 06:49
Reporternlangenberg Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Product Version0.19.2 
Target VersionFixed in Version 
Summary0005239: Other change bug status tresholds when you are the assigned person
Description

One thing in Mantis I don't like is the thing that tresholds are applied to all persons with the same user access level.

Fortunately, Mantis already made several exceptions. A good example is with the "reporter" access level: reporters cannot reopen bugs, only when you are the reporter of it.

For me, and probably also for others, it would be nice to also have such exceptions for "developer" access level. Especially the right to set a bug to the "resolved" status should typically only be allowed when you are the "owner" of the bug. (The "assigned to" person).

Otherwise, any developer can set a bug to "resolved", while they aren't the owner of it at all. That sounds a bit strange to me.

Another second good example where I need this feature is for the feedback status. If a developer asks for feedback he/she must be able to set the bug back to assigned when the correct feedback is given. But I don't want that developers assign NEW issues. Only when they are the owner of the problem, they can ask feedback and set the status back to assigned.

The third, and for me last, usefull thing is that developers may not set issues to "closed" that they have resolved. But a developer may verify a solution from another developer and set it to "closed". This is in fact the other way around when compared to the above two items: a developer may NOT set an issue to closed when he is the owner of it, developers that are not owner of the issue may set it to resolved.

I have implemented the above feature requests in my personal installation in a quick hack. It is VERY simple.

In my config_inc.php I have added a new variable named "g_handler_set_status_threshold" which lists the tresholds when the
"assigned to" name is the logged in username.

[CODE IN CONFIG_INC.PHP]
$g_set_status_threshold = array( ASSIGNED => MANAGER, FEEDBACK => MANAGER, RESOLVED => MANAGER, CLOSED => DEVELOPER );
$g_set_handler_status_threshold = array( ASSIGNED => DEVELOPER, FEEDBACK => DEVELOPER, RESOLVED => DEVELOPER, CLOSED => MANAGER );
[/CODE IN CONFIG_INC.PHP]

[CODE IN ACCESS_API.PHP, FUNCTION access_get_status_threshold]
function access_get_status_threshold( $p_status, $p_project_id = ALL_PROJECTS ) {
$f_bug_id = gpc_get_int( 'bug_id' );
$t_handler_thresh_array = config_get( 'set_handler_status_threshold' );
$t_thresh_array = config_get( 'set_status_threshold' );
if ( isset( $t_thresh_array[ $p_status ] ) ) {
if ( bug_get_field( $f_bug_id, 'handler_id' ) == auth_get_current_user_id() ) {
return $t_handler_thresh_array[$p_status];
} else {
return $t_thresh_array[$p_status];
}
} else {
return config_get( 'update_bug_status_threshold' );
}
}
[/CODE IN ACCESS_API.PHP]

Code explanation is simple, when the "assigned to" username is equal to the current logged in username, return treshold value from t_handler_thresh_array, otherwise return value from t_thresh_array.

With this simple adjustment all three above features are realized.

Please give comment if I have introduced new/unwanted bugs with this hack. If it is a good solution and more people are requesting this feature, please add it in the next Mantis release.

TagsNo tags attached.

Relationships

has duplicate 0023580 closedatrol Update the Issue 

Activities

nlangenberg

nlangenberg

2005-02-14 10:50

reporter   ~0009307

I have done some testing, and found the first bug with the add-on:
the /admin/workflow.php fails checking with an application error 200.

Have to fix this, but this shouldn't be hard.

Issue History

Date Modified Username Field Change
2005-02-14 09:57 nlangenberg New Issue
2005-02-14 10:50 nlangenberg Note Added: 0009307
2005-03-19 08:19 thraxisp Assigned To => thraxisp
2005-03-19 08:19 thraxisp Status new => assigned
2009-05-19 20:05 thraxisp Assigned To thraxisp =>
2009-05-19 20:05 thraxisp Status assigned => new
2017-01-18 10:10 atrol Severity major => feature
2017-11-02 06:49 atrol Relationship added has duplicate 0023580