The proposed idea is useful, however, my only concern is that there are two hard-coded assumptions:

• "feedback" exists and it is the feedback status.
• After adding a bugnote by the reporter, the status to go to is "feedback", not "in progress" or "assigned" or whatever else.

To handle these issues there is one of two options:

• Do this as part of a post processing function that gets activated after changes to a bug.
• Add two configuration options, one to indentify the feedback status (if any), and the other to identify the return status. Of course, this option is easier to implement.

Sorry vboctor, I didn't understand your 2nd point ("After adding..."). This might be just because I am not English-Native...

Do you mean the status should change to "Feedback" when adding a bugnote?

I thought if a developer has problems (e.g. understanding or reproducing...) a bug, he will set the status to feedback. By color-coding the bug you will see in the list that the bug was looked at, but fixing is paused until feedback will be provided.
When someone provides more input (=feedback) the status should change to a different state (For me it would be sufficient to set it back to New, you might prefer to make this an option...) so when you look at the list of open issues you see that there is an issue that someone could try to fix.

What I meant is that we need to have two config options:

• $g_bug_feedback_status = FEEDBACK;
• $g_bug_feedback_provided_status = NEW;

In some cases the bug_feedback_provided_status should depend on the bug state. For example, set to "ASSIGNED" if bug has a handler set, otherwise, set to "NEW". This can only be achieved by my first proposed solution (i.e. post processor function). The post process function can check if handler is set, set status to "ASSIGNED" otherwise set status to "NEW".

Now I understand!
And, yes, I also understand why you wrote that option 2 would be much easier to implement.
I personally would prefer the option that's available earlier.
The hardcoded solution like the one your just described, is probably not 100% optimal, but it surely would be a huge improvement over the existing behaviour.

If this would be implemented another filter-checkbox "hide status" "feedback" would make sense.

So you don't see bug-reports where feedback is required to continue to work on these bugs.

I provided changes to achieve that.
See report 0003919

Cheers!

See also 0004469

0004469 : If the status would fall back to what it was before, this naturally would be best.

However, for my simple requirements, I just inserted the following lines in bugnote_api.php, at line 127.

    # if it was FEEDBACK its NEW_ now
    if (bug_get_field($p_bug_id,'status')==FEEDBACK)
    {
       bug_set_field( $p_bug_id, 'status', NEW_ );
    }

Do we want the status to change back only if the person who added the issue is the "reporter" of the issue, or any user?

In my case: any user.

(User A might report, Deverloper B says "Can't reproduce" -> feedback, User B posts a guid how to reproduce)

I think, there should be a "reply to feedback" button instead of "change status to" if the current status is "feedback" - so every user can add a note to the bug for additional information.

And only when the user want to reply to the feedback he should use the "reply to feedback" button.

[edit]
But the workflow is not quite right at the moment - because there is no way to assign a person to the current status.
[/edit]

bearbeitet am: 09-13-04 10:46

As our company grows, I now feel the need for a more sophisticated solution:
After providing feedback, the status should fall back to what it was before it was set to "Feedback".

(We now have people, who only look at new issues and check if they are nonsense or should be seen by the DevTeam.)

Btw: This is a "better" patch.
Bugs that have no developers assigned, are reset to new, others are reset to "assigned".

    # if it was FEEDBACK its NEW_ now
    if (bug_get_field($p_bug_id,'status')==FEEDBACK)
    {
       if (bug_get_field($p_bug_id, 'handler_id') == 0)
         {   bug_set_field( $p_bug_id, 'status', NEW_ );  }
       else
         {   bug_set_field( $p_bug_id, 'status', ASSIGNED );  }
    }

(insert this block into function bugnote_add, right before the last line "return ...")

Implemented the logic to revert back to new/assigned if the current status is FEEDBACK and the author of the note is the reporter of the issue.

I would appreciate it, if a superior logic would have been implemented:

1. History popping is easy, see 0004469:0022183.
2. Make it a config option, wether the handler or the reporter is requested to give feedback.