View Issue Details

IDProjectCategoryView StatusLast Update
0009174mantisbtfeaturepublic2008-07-30 02:29
Reporterdjcarr Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Product Version1.2.0a1 
Summary0009174: A more specific handle_bug_threshold based on status
Description

The current config option $g_handle_bug_threshold, if set to REPORTER has a couple of problems - too many users are displayed in the Assign To combo, and inappropriate users can be assigned.

Users in the Assign-To list needs to be filtered according to the current status (or the status implicit when using a "Change Status To" page).

Proposal: a new array option $g_handle_bug_status_threshold which if used will override $g_handle_bug_threshold, since it defines the user level needed to handle each status. It will also obsolete the need for some other options like

For example: the following option would go a long way towards providing whole lifecycle assigns, as issues can be assigned to pretty much anyone early on, but not later on during development and testing.

$g_handle_bug_status_threshold = array(
    NEW_            =>  REPORTER,
    FEEDBACK        =>  REPORTER,
    ACKNOWLEDGED        =>  UPDATER,
    CONFIRMED       =>  UPDATER,
    ASSIGNED        =>  DEVELOPER,
    RESOLVED        =>  UPDATER,
    CLOSED          =>  UPDATER
    );
Additional Information

(can this be related to 0009173 please?)

TagsNo tags attached.

Relationships

related to 0009173 new Support handlers through whole defect lifecycle (issues assigned to non-developers) 

Activities

vboctor

vboctor

2008-07-13 16:36

manager   ~0018466

We currently have the following for controling who can change the status field:

# status change thresholds
$g_update_bug_status_threshold = DEVELOPER;
djcarr

djcarr

2008-07-29 20:56

reporter   ~0018914

Hi Victor. Sorry, thats not quite what I'm talking about. That config option controls who can SET the status. I'm talking about the ability to refine who can RECEIVE an assign.

Essentially I'm just proposing an extension of $g_handle_bug_threshold to be an array of thresholds rather than just one.

djcarr

djcarr

2008-07-30 02:29

reporter   ~0018916

Last edited: 2008-07-30 21:06

I had a look at 1.1.2 (sorry, I haven't had a chance to look at 1.2.0a yet) and there are 11 locations where "config_get('handle_bug_threshold')" is used:

bug_api.php,1173: if ( ( $c_user_id != NO_USER ) && !access_has_bug_level( config_get( 'handle_bug_threshold' ), $p_bug_id, $p_user_id ) ) {
bug_assign.php,57: access_ensure_bug_level( config_get( 'handle_bug_threshold' ), $f_bug_id, $f_handler_id );
bug_change_status_page.php,68: if ( !access_has_bug_level( config_get( 'handle_bug_threshold' ), $f_bug_id, $f_handler_id ) ) {
bug_change_status_page.php,226: if ( ( $f_new_status >= $t_resolved ) && access_has_bug_level( config_get( 'handle_bug_threshold' ), $f_bug_id ) ) {
bug_report_advanced_page.php,203: <?php if ( access_has_project_level( config_get( 'handle_bug_threshold' ) ) ) { ?>
bug_report_page.php,186: <?php if ( access_has_project_level( config_get( 'handle_bug_threshold' ) ) ) { ?>

filter_api.php,1753: if ( access_has_project_level( config_get( 'handle_bug_threshold' ) ) ) {
filter_api.php,3341: if ( access_has_project_level( config_get( 'handle_bug_threshold' ) ) ) {
html_api.php,1020: ( access_has_bug_level( config_get( 'handle_bug_threshold' ), $p_bug_id, $t_current_user_id ) ) ) {

html_api.php,1026: ( access_has_bug_level( config_get( 'handle_bug_threshold' ), $p_bug_id, $t_reporter_id ) ) ) {
print_api.php,465: $p_threshold = config_get( 'handle_bug_threshold' );

If in 1.2.0a these calls could be wrapped in a new function:

access_api.php:

# --------------------
# get the access level required to handle the bug, ie. to have the bug assigned to the given user
#  If there is no specific differentiated access level, use the
#  generic handle_bug_threshold
function access_get_handle_threshold( $p_status=null ) {
    return config_get( 'handle_bug_threshold' );
}

So that the calls look like:

... access_has_bug_level( access_get_handle_threshold( $f_new_status / where applicable / ), $p_bug_id, $p_user_id ) ...

Then this will make it really easy for users to expand or insert a plugin at this point.