View Issue Details

IDProjectCategoryView StatusLast Update
0024195mantisbtfeaturepublic2018-03-31 15:18
ReporterStarbuck Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version2.12.0 
Summary0024195: Add hook for custom handling of feedback
Description

bug_update.php includes the following:

# Handle the reassign on feedback feature. Note that this feature generally
# won't work very well with custom workflows as it makes a lot of assumptions
# that may not be true. It assumes you don't have any statuses in the workflow
# between 'bug_submit_status' and 'bug_feedback_status'. It assumes you only
# have one feedback, assigned and submitted status.

Many tickets have been added over the last 15 years expressing confusion with the existing feedback processing and a need for more refinement. The reassignment feature is a hardcoded answer to a diversity of problem scenarios, and as the comments indicate, it could use some improvement.

I'm proposing adding a hook here, which if processed by a plugin will cause this code to be skipped. On implementation, a plugin developer should be able to use $t_existing_bug and $t_updated_bug to return a new $t_updated_bug, or maybe just a new status and handler_id for the updated bug.

I could use this myself and will try to implement if the ticket is confirmed, along with a plugin as a POC.

Additional Information

Consider this code from bug_update.php
The currently hardcoded rules are as follows:

if( $t_bug_note->note &&
    config_get( 'reassign_on_feedback' ) &&
    $t_existing_bug->status == config_get( 'bug_feedback_status' ) &&
    $t_updated_bug->status != $t_existing_bug->status &&
    $t_updated_bug->handler_id != $t_current_user_id &&
    $t_updated_bug->reporter_id == $t_current_user_id
) {
    if( $t_updated_bug->handler_id != NO_USER ) {
        $t_updated_bug->status = config_get( 'bug_assigned_status' );
    } else {
        $t_updated_bug->status = config_get( 'bug_submit_status' );
    }
}

Possible alternatives to the results there include:

  • Set the status to a custom Feedback Returned
  • Set the status back to what it was before it went for Feedback.
  • Set the handler_id to the user that initially set the Feedback flag (who might be a manager) rather than the original handler who might be the developer
TagsNo tags attached.

Activities

cproensa

cproensa

2018-03-31 05:36

developer   ~0059379

Unless mistaken, a plugin can be built based on current events to manage any of those proposed alternatives.

Starbuck

Starbuck

2018-03-31 15:18

reporter   ~0059384

Looking closer, that is correct...

reassign_on_feedback gets a chance to change the status,
then bug_get_status_for_assign() gets a chance to change it again based on those results,
and then EVENT_UPDATE_BUG_DATA is invoked.

In order for a plugin to fully handle this scenario:
The results of the default reassign_on_feedback and bug_get_status_for_assign() will need to be ignored.
The plugin needs to gpc_get_string( 'bugnote_text', '' ) to determine if a note is present (as does the default handler).
The plugin needs to get the real original $t_updated_bug->status with gpc_get_int( 'status', $t_existing_bug->status ).
It can then use that unmodified data to do its own handling, and finally re-invoke bug_get_status_for_assign.

If that is all correct then I believe the doc for EVENT_UPDATE_BUG_DATA just needs a hint at this, and an example plugin could help to resolve a number of questions on this topic.