View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009174 | mantisbt | feature | public | 2008-05-20 20:20 | 2008-07-30 02:29 |
Reporter | djcarr | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.2.0a1 | ||||
Summary | 0009174: 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.
| ||||
Additional Information | (can this be related to 0009173 please?) | ||||
Tags | No tags attached. | ||||
related to | 0009173 | new | Support handlers through whole defect lifecycle (issues assigned to non-developers) |
We currently have the following for controling who can change the status field: |
|
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. |
|
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 ) ) { filter_api.php,1753: if ( access_has_project_level( config_get( 'handle_bug_threshold' ) ) ) { html_api.php,1026: ( access_has_bug_level( config_get( 'handle_bug_threshold' ), $p_bug_id, $t_reporter_id ) ) ) { If in 1.2.0a these calls could be wrapped in a new function: access_api.php:
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. |
|