Empty default owner (assignee or QA) causes "Reassign bug to owner and QA contact of selected component to NOOP

RESOLVED FIXED in Bugzilla 2.18

Status

()

defect
RESOLVED FIXED
17 years ago
7 years ago

People

(Reporter: benc, Assigned: timeless)

Tracking

unspecified
Bugzilla 2.18
Bug Flags:
approval +
blocking2.18 +

Details

Attachments

(1 attachment)

Reporter

Description

17 years ago
Based on Bug 107310, the default QA of Image Blocking was set to "" (I didn't
know you could do this...)

OBSERVED:
When you are in Image Blocking bug, and you set the default owner and QA to the
default via the radio buttons above submit, you get no change to the QA.

EXPECTED:
Should set it to "".

NOTE: I don't think you should be allowed to set the values to "", I think we
should be creating placeholders if necessary.
Assignee

Updated

17 years ago
Severity: normal → major
By design, Bugzilla allows empty QA contacts, because not all
products/components have them (some of the Webtools components come to mind). 
Forcing everyone to have them would be a policy decision and would be up to
mozilla.org to set it that way for that component.  This means the proper fix
here is to make "set to defaults" clear the QA contact if the component doesn't
have one.
OS: Windows 98 → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Sigh. Bring on custom mail fields! :)
Severity: major → normal
Summary: Empty default owner (assignee or QA) causes "Reassign bug to owner and QA contact of selected component " to NOOP → Empty default owner (assignee or QA) causes "Reassign bug to owner and QA contact of selected component to NOOP
*** Bug 225104 has been marked as a duplicate of this bug. ***
*** Bug 226679 has been marked as a duplicate of this bug. ***
Reporter

Comment 5

16 years ago
Because of the new b.m.o default owner scheme, we have a lot of components that
have empty QA fields.

When I transfer bugs to these components, and I reset the ownerships to default,
I  still get stuck owning the bug because the "" doesn't over-write the current
value.

This behavior is either: creating a lot of extra bugmail, as people have to make
two changes (and assign to nobody@mozilla.org the second time)

-or- 

Not clearing the fields, which leaves a lot of people stuck w/ bugs they should
not QA own.

Is this something where the database doesn't handle a change to NULL, or
something in the processing cgi?
yeah, it's a CGI problem.  The CGI assumes if you didn't submit one, you didn't
intend to change it.
Reporter

Comment 7

16 years ago
Is related to this commnet?

http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/process_bug.cgi#1127

1127         # Consider NULL db entries to be equivalent to the empty string

So, currently, the only way a field could get created as empty is because when
we create the bug, the product/component lookup simply doesn't write anything to
owner/qa if it is empty? Besides that, it doesn't seem like any operation can
actually put "" into a field.

It also seems like it is impossible to assign bug ownership to "", because of;

http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/process_bug.cgi#906
906         if (!defined$::FORM{'assigned_to'} ||
907             trim($::FORM{'assigned_to'}) eq "") {
908             ThrowUserError("reassign_to_empty");

But it sounds like there might be no place that the cgi's actually write "" to
existing field entries.
(In reply to comment #7)
> Is related to this commnet?
> 
> http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/process_bug.cgi#1127
> 
> 1127         # Consider NULL db entries to be equivalent to the empty string

No, this is actually unrelated.

> It also seems like it is impossible to assign bug ownership to "", because of;
> 
> http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/process_bug.cgi#906
> 906         if (!defined$::FORM{'assigned_to'} ||
> 907             trim($::FORM{'assigned_to'}) eq "") {
> 908             ThrowUserError("reassign_to_empty");
> 
> But it sounds like there might be no place that the cgi's actually write "" to
> existing field entries.

That is correct.  Assignee shouldn't ever be able to be blank.

What we really need to do is allow QA Contact to be blank (because it's allowed
to be, you just can't set it that way because it assumes the "assign to default"
if you do that).
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Assignee

Comment 9

15 years ago
Assignee: myk → timeless
Status: NEW → ASSIGNED
Assignee

Updated

15 years ago
Attachment #146747 - Flags: review?(justdave)
Assignee

Comment 10

15 years ago
bmo now has many components w/o qa contacts. reassigning to defaults is failing
much more often today than in the past. we really should get this fixed for 2.18
Flags: blocking2.18?
Flags: approval?
Comment on attachment 146747 [details] [diff] [review]
support zeroing the qa contact while reassigning

ooof.  We actually allow this?	Ah well, this'll work for now, we can fix the
referential integrity problems this'll create in another bug, it's not worth
fixing as part of this one.  (The lack of a QA Contact should really be NULL,
not 0, since there's no user with a userid of 0, but we have NOT NULL set on
the qacontact field at the moment, which kind of prevents that...)
Attachment #146747 - Flags: review?(justdave) → review+
Flags: blocking2.18?
Flags: blocking2.18+
Flags: approval?
Flags: approval+
Target Milestone: Bugzilla 2.20 → Bugzilla 2.18
Whiteboard: [applied to b.m.o]
Assignee

Comment 12

15 years ago
mozilla/webtools/bugzilla/process_bug.cgi 	1.203
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [applied to b.m.o]
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.