1036834 - "Reset Assignee to default" checkbox should also change the bug status from "ASSIGNED" to "NEW"

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Ed Morley [:emorley]]

Broken out from the recent dev.platform newsgroup discussion (subject: "Misunderstood the "Assigned" at bugs").

To avoid cases where the assignee of a bug is [e-mail], but the bug status is still ASSIGNED - it would be good if the "Reset Assignee to default" checkbox on show_bug.cgi would reset the status from ASSIGNED to NEW.

https://github.com/bugzilla/bugzilla/blob/eb527a5c1ccff25425d5a080919ae88dc6d60533/Bugzilla/WebService/Bug.pm#L3980
sub reset_assigned_to {
    my $self = shift;
    my $comp = $self->component_obj;
    $self->set_assigned_to($comp->default_assignee);
}

We'll also presumably want to update the docs here:
https://github.com/bugzilla/bugzilla/blob/eb527a5c1ccff25425d5a080919ae88dc6d60533/Bugzilla/WebService/Bug.pm#L3980

Comment 1

[Ed Morley [:emorley]]

Attachment: WIP

Likely not correct (but I couldn't get the Vagrant VM working), and definitely not ideal given the hardcoded ASSIGNED/IN_PROGRESS (albeit other places in Bug.pm do it) but maybe something like this?

That said - should this be something that the show_bug.cgi UI updates, rather than just on submit? (That way someone can override if desired)

Comment 3

[Ed Morley [:emorley]]

Per bug 475409 comment 27 this isn't a dupe after all.

Comment 4

[Ed Morley [:emorley]]

Attachment: "Reset Assignee to default" should reset the bug status too

When using the "Reset Assignee to default" feature, users frequently
forget to set the bug status back to "CONFIRMED"/"NEW" from
"IN_PROGRESS"/"ASSIGNED". This patch makes that happens automatically.

Now that I've gotten docker to cooperate via bug 1102239, I've finally been able to test the WIP patch from 4 months ago, and it (to my surprise) works without any changes.

Reattaching since I've rebased it & improved the commit message.

Comment 5

[Ed Morley [:emorley]]

The queries in comment 1 still stand.

Comment 6

[Frédéric Buclin]

Comment on attachment 8527313 [details] [diff] [review]
"Reset Assignee to default" should reset the bug status too

>+++ b/Bugzilla/Bug.pm

>+    if ($current_status eq 'IN_PROGRESS' or $current_status eq 'ASSIGNED') {

These bug statuses are not hardcoded in our codebase, and so won't work once an admin customize them or add more bug statuses (such as RedHat). We intentionally removed as much references to hardcoded bug statuses from our codebase as possible. Please don't bring them back.


>+        # Change the bug status back to the default new bug status.
>+        my @valid_statuses = @{ $self->new_bug_statuses($product) };
>+        my $default_bug_status = $self->default_bug_status(@valid_statuses);

This doesn't work for unprivileged users/assignees. new_bug_statuses() will return UNCONFIRMED and so everconfirmed will flip back to false, which is not the desired behavior, and an error will be thrown as an unprivileged user is not allowed to edit everconfirmed.

Comment 7

[Ed Morley [:emorley]]

(In reply to Frédéric Buclin from comment #6)
> Comment on attachment 8527313 [details] [diff] [review]
> "Reset Assignee to default" should reset the bug status too
> 
> >+++ b/Bugzilla/Bug.pm
> 
> >+    if ($current_status eq 'IN_PROGRESS' or $current_status eq 'ASSIGNED') {
> 
> These bug statuses are not hardcoded in our codebase, and so won't work once
> an admin customize them or add more bug statuses (such as RedHat). We
> intentionally removed as much references to hardcoded bug statuses from our
> codebase as possible. Please don't bring them back.
> 
> 
> >+        # Change the bug status back to the default new bug status.
> >+        my @valid_statuses = @{ $self->new_bug_statuses($product) };
> >+        my $default_bug_status = $self->default_bug_status(@valid_statuses);
> 
> This doesn't work for unprivileged users/assignees. new_bug_statuses() will
> return UNCONFIRMED and so everconfirmed will flip back to false, which is
> not the desired behavior, and an error will be thrown as an unprivileged
> user is not allowed to edit everconfirmed.

For both of these, what should I use instead? I've paged so much of this bug out of my head by now I don't know if it's worth the cost:benefit for me to dig into it more, unless there's an easy way to do both of these?

Comment 8

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley] from comment #7)
> For both of these, what should I use instead? I've paged so much of this bug
> out of my head by now I don't know if it's worth the cost:benefit for me to
> dig into it more, unless there's an easy way to do both of these?

Comment 9

[Frédéric Buclin]

(In reply to Ed Morley [:edmorley] from comment #7)
> For both of these, what should I use instead?

My concern is that different teams can have different workflows. In some cases, the default assignee is a real user, in some cases, it's not (e.g. BMO). Fixing bug 369078 would make things easier, because if the bug has no assignee, then it probably makes sense to "reset" the bug status. If it's a real user, it's questionable if "resetting" the bug status is really expected or not.

One way to fix the problem could be to add a new parameter to decide what to do when a bug assignee is reset. If the parameter is left empty, no automatic bug status change would happen. Else it would use the value specified by this parameter.

Now the question is: is this feature important enough to worth a parameter? I have no strong opinion on this (we already have several similar parameters).

Comment 10

[Ed Morley [:emorley]]

Thank you for the additional info, agree with your points - this is just sadly another bug that would be so much easier to fix if Bugzilla were only being used by one org (or if Mozilla had forked for BMO), there are just too many factors to take into account otherwise. I think at this point I'll unassign myself since I can see the rabbit hole deepening, for what was just me trying to quickly scratch an itch.

Comment 11

[Frédéric Buclin]

(In reply to Ed Morley [:edmorley] from comment #10)
> Thank you for the additional info, agree with your points - this is just
> sadly another bug that would be so much easier to fix if Bugzilla were only
> being used by one org

Which means that a similar bug can be filed into the bmo product to have this specific customization for bmo only. ;)

Comment 12

[Ed Morley [:emorley]]

True, I suspect it may be best to wait until after the v5 release and subsequent BMO merge/update - there's going to be enough conflict resolution as it is!

Comment 13

[:glob ✱]

as this is an upstream bug i'm removing the bmo specific references.
a bmo specific implementation is being tracked in bug 1152818.

Comment 14

[jose i cabrera]

We are in need of this function and I don't want to go and open another bug, if there is already an open bug.  Can at least we add a choice in the administration for the administrators to make this change?

Comment 15

[jose i cabrera]

Is anything going to happen with this?  Otherwise, I need to go into the code and make the changes myself.  Thoughts?  Comment?  Anything? Is anybody out there?  :-)