View Issue Details

IDProjectCategoryView StatusLast Update
0004469mantisbtfeaturepublic2016-04-06 09:36
Reporterbpfennig Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Summary0004469: "Reply To Feedback" Button
Description

This could be a usefull feature.

Situation:

  1. A reporter adds an issue.
  2. One of our testers assigned to this bug for reproducing.
  3. The tester could not reproduce the bug and set the status for feedback from the reporter.
  4. The reporter adds a bugnote or change the description, this could be done by a "Reply To Feedback" button. After that changes the status and assigned to are set back to the settings before the status changed to feedback.

It should also be possible to assign every user to an issue - so the user knows that he have to act with the issue now.

TagsNo tags attached.

Relationships

has duplicate 0006592 closedgrangeway my view and feedback 
related to 0003378 new who's feeding back to who? 
related to 0003730 closedvboctor Change status upon feedback 
related to 0002442 closedvboctor better handling of status FEEDBACK (status change after feedback by bugnote) 
related to 0006061 closedcproensa Issues being put back to "Assigned" if assignment changes (to another user) when on different status. 
related to 0016454 assigneddregad Missing something with $g_reassign_on_feedback 

Activities

jlatour

jlatour

2004-09-02 15:03

reporter   ~0007409

The question is whether we need another status, or whether we can use an existing status like 'new'. Any thoughts?

bpfennig

bpfennig

2004-09-03 04:07

reporter   ~0007421

I think "feedback" is not a normal status in the status workflow because it "jumps out" the normal workflow. "Feedback" should be reachable from every other status.

So, after the reply it should be jump back to the old status before the "feedback".
Another status is not needed, but the "Change Status To" popup should be replaced by a "Reply Feedback" button if the current status is "feedback".

jlatour

jlatour

2004-09-03 06:23

reporter   ~0007422

Humm, that's not a bad idea. We just have to be able to figure out the last status, possibly from the history.

polzin

polzin

2005-04-05 10:47

reporter   ~0009711

I would appreciate a simple solution (a predefined exit status, new or assigned) to, in contrast to no solution.
Popping back to the previous status would be even better, but I fear that it will never come. :-)

polzin

polzin

2005-05-17 15:22

reporter   ~0010160

Last edited: 2005-05-17 15:26

I found a patch somewhere. Perhaps someone is interested. If someone is assigned to the bug, than giving feedback pop´s back to ASSIGNED, if not to NEW.

Before bug_update_date in bugnote_add in core/bugnote_api.php

<pre>

  # if it was FEEDBACK its NEW_ now
  #
  # new config option: g_bug_feedback_status = FEEDBACK;
  # if g_feedback_status is not set, the popping back is disabled.
  # (default behaviour).
  #
    if ( bug_get_field($p_bug_id, 'status')== config_get( 'bug_feedback_status' ) )
    {
        if ( bug_get_field( $p_bug_id, 'handler_id') == 0 )
            bug_set_field( $p_bug_id, 'status', config_get( 'bug_submit_status' ) );
        else
            bug_set_field( $p_bug_id, 'status', config_get( 'bug_assigned_status' ) );
    }

</pre>

Sorry for the layout, but preformatted text is still misbehaving (word wrapping), dispite of 0004762 being closed, sigh...

olegos

olegos

2008-11-13 15:02

reporter   ~0019877

+1 (I was going to enter this feature request myself, then found this)

I think there should be "Provide Feedback" button in Feedback state, treated same way as "Reopen Issue" button -- with config variables for who it's available to and what state the issue should transition to (possibly with a special value of "previous").

cas

cas

2009-01-23 04:52

reporter   ~0020692

Any chance of adding this simple but very effective option into the 1.2.0 version ?

polzin

polzin

2009-01-23 05:14

reporter   ~0020693

I have improved my patch from 3.5 years ago... :-)
The new workflow:
Step 1: Request feedback and set "assigned to" to the one you request the feedback from (This requires that all reporters can be handlers, but has the great advantage that all reporters can see easily if they are in charge of an action)
Step 2: If the bug is assigned to me and is on "feedback" and I submit a note, than the history is used to find the previous handler and status and "assigned to" pop back to the last state.

The different workflow requires some other patches, but I find this very useful. If there is interest in the patch, I can try to extract one.

polzin

polzin

2009-06-17 10:55

reporter   ~0022183

Last edited: 2009-06-17 10:57

View 2 revisions

The changes for the behaviour descripted in the last bugnote:

in bugnote_api.php:

if ( ( bug_get_field($p_bug_id, 'status') == FEEDBACK ) &&
( bug_get_field($p_bug_id, 'handler_id' ) == $c_user_id ) ) {
history_status_pop_back( $p_bug_id );
}

somewhere, e.g. in history_api.php:
function history_status_pop_back( $p_bug_id )
{
$t_mantis_bug_history_table = config_get( 'mantis_bug_history_table' );
$c_bug_id = db_prepare_int( $p_bug_id );

# grab history and display by date_modified then field_name
$query = &quot;SELECT *
    FROM $t_mantis_bug_history_table
    WHERE bug_id='$c_bug_id' and field_name='status'
    ORDER BY date_modified DESC,id DESC
    LIMIT 1&quot;;
$result = db_query( $query );
$count = db_num_rows( $result );   
if ( $count == 1 ) {
    $row = db_fetch_array( $result );
    bug_set_field( $p_bug_id, 'status', $row['old_value'] );
    bug_set_field( $p_bug_id, 'handler_id', $row['user_id'] );
}

}

polzin

polzin

2009-07-21 07:32

reporter   ~0022542

I wrote a patch that implement the following workflow:

  • A issue with status feedback may be assigned to any reporter.
  • When requesting feedback, the "assigned to" defaults to the reporter.
  • Then a bugnote is entered, status and feedback pop back.

I have it against 1.1.8, but could port it to 1.2.X if there is interest.

Changing the "assigned to" is a tradeoff:

  • It is definitely clear, who's duty is the next action (for me this is very important): Always look at "assigned to". Otherwise it would be implicit: If status is feedback, it may be the reporter who is in charge, it may be that he already answered.
  • The "responsible developer" is only implicit.

See also 0008140, reply to note, which works very good together with this.

vboctor

vboctor

2009-10-14 01:20

manager   ~0023172

I've just checked in 0003730 which does the following:

  1. If the reporter adds a note and the status is FEEDBACK, then revert back NEW if unassigned.
  2. If the reporter adds a note and the status is FEEDBACK, then revert back to ASSIGNED if the issue is assigned.

The fix doesn't however pop the status from the history.

polzin

polzin

2009-10-14 03:29

reporter   ~0023175

History popping is easy, see 0004469:0022183.
(This patch assumes that the handler not the reporter is requested to give feedback. Best would be a configurable option.)

dregad

dregad

2014-10-10 05:41

developer   ~0041522

Work-in-progress fix for this can be found at https://github.com/dregad/mantisbt/tree/feedback-prev-stat

Issue History

Date Modified Username Field Change
2004-09-02 12:07 bpfennig New Issue
2004-09-02 15:03 jlatour Note Added: 0007409
2004-09-02 15:03 jlatour Status new => feedback
2004-09-03 04:07 bpfennig Note Added: 0007421
2004-09-03 06:23 jlatour Note Added: 0007422
2005-04-05 10:47 polzin Note Added: 0009711
2005-05-17 11:22 ryandesign Relationship added related to 0003378
2005-05-17 15:22 polzin Note Added: 0010160
2005-05-17 15:26 polzin Note Edited: 0010160
2006-02-27 16:27 ryandesign Relationship added related to 0006592
2006-03-02 06:41 ryandesign Relationship added related to 0003730
2006-03-02 06:41 ryandesign Relationship added related to 0002442
2008-07-28 14:20 grangeway Status feedback => acknowledged
2008-07-28 15:22 grangeway Relationship replaced has duplicate 0006592
2008-11-13 15:02 olegos Note Added: 0019877
2009-01-23 04:52 cas Note Added: 0020692
2009-01-23 05:14 polzin Note Added: 0020693
2009-06-17 10:55 polzin Note Added: 0022183
2009-06-17 10:57 polzin Note Edited: 0022183 View Revisions
2009-07-21 07:32 polzin Note Added: 0022542
2009-10-14 01:20 vboctor Note Added: 0023172
2009-10-14 03:29 polzin Note Added: 0023175
2014-10-10 05:40 dregad Relationship added related to 0006061
2014-10-10 05:41 dregad Note Added: 0041522
2016-04-06 09:36 dregad Relationship added related to 0016454