Closed
Bug 36257
Opened 25 years ago
Closed 20 years ago
Have the QA Contact field appear in New Bug submission form
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement, P3)
Bugzilla
Creating/Changing Bugs
Tracking
()
RESOLVED
FIXED
Bugzilla 2.20
People
(Reporter: lchiang, Assigned: shane.h.w.travis)
References
Details
Attachments
(2 files, 7 obsolete files)
(deleted),
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
justdave
:
review+
|
Details | Diff | Splinter Review |
Have the QA Contact field be editable and appear in New Bug submission form
When submitting a new bug report, the QA Contact field does not appear in the
new bug form.
Sometimes the QA contact may differ than the default QA contact that gets
assigned. Being able to change it at bug submission time would reduce bug email
notification.
If someone knows who the QA contact should be, it would be less steps to change
it.
Suggest:
QA contact field be added with the text "(Leave blank to assign to default
component QA contact)"
Thanks!
Comment 1•25 years ago
|
||
I agree. Also help on test bugs etc.
Not sure, what Lisa means with "editable".
by "editable", I mean that I can put text in that field. I guess it is already
assumed to be so.
Comment 3•25 years ago
|
||
Depends on who you mean with *I*... :-). I can edit it (just tried it), but not
everybody: <http://bugzilla.mozilla.org/confirmhelp.html>. Do you suggest any
changes to the current system? If not, please adjust the summary, so I can
recover from my confusion :).
I will relieve you from your confusion. :-) I really just want the QA contact
field to be in the new bug submission form.
Summary: Have the QA Contact field be editable and appear in New Bug submission form → Have the QA Contact field appear in New Bug submission form
there's been a long standing terry philosophy about making the enter bug form as
easy as possible. not sure i agree in this case though.
Comment 6•24 years ago
|
||
We can have several of those, targetted at different user groups. I usually have
to change a bug right after filing it to add keywords etc.. IMO, we should have
/a/ bug enter form which allows me to set all (appropriate) fields. Should I
widen this bug?
Comment 7•24 years ago
|
||
We need an advanced user section in the enter_bug page.
Comment 8•23 years ago
|
||
you have to log in before you can see the enter bug screen anyway. Why not
remove both fields unless the user has editbugs, and then let them edit either?
Severity: normal → enhancement
Comment 9•23 years ago
|
||
Bug #76770 and bug #40970 are related since the reporter is supposedly supposed
to be able to edit bugs regardless of editbugs. If we decide to remove this, I
agree we don't need assignee and QA.
See also bug #25521 about adding keywords to enter_bug.
Target Milestone: --- → Bugzilla 2.16
Comment 10•23 years ago
|
||
-> Bugzilla product, Creating Bugs component, reassigning.
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Updated•23 years ago
|
Whiteboard: [people:qa] enter_bug
Comment 11•23 years ago
|
||
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut. Thus this is being retargetted at 2.18. If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 12•22 years ago
|
||
I actually made that change to our copy of 2.17 for this. it was very simple
to do this and we found it usefull. problem is i have never made a patch for
such a change before once i figure this out i will be glad to post my changes
as a patch but for now here they are:
create.html.tmpl (@ line 146 or so basically right after the assigned to field:
[% IF Param('useqacontact') %]
<tr>
<td align="right">
<b><u>Q</u>A Contact:</b>
</td>
<td colspan="7">
<input name="qa_contact" accesskey="q"
value="[% bug.qa_contact.email FILTER html %]" size="32">
(Leave blank to assign to default component QA contact)
</td>
</tr>
[% END %]
post_bug.cgi: i changed the section on adding the qa_contact info to this
if (Param("useqacontact")) {
SendSQL("SELECT initialqacontact FROM components " .
"WHERE id = $component_id");
my $qa_contact = FetchOneColumn();
if (defined $qa_contact && $qa_contact != 0) {
if ($::FORM{'qa_contact'} eq "") {
$::FORM{'qa_contact'} = $qa_contact;
} else {
$::FORM{'qa_contact'} = DBNameToIdAndCheck(trim($::FORM{'qa_contact'}));
}
push(@bug_fields, "qa_contact");
}
}
Comment 13•21 years ago
|
||
Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18.
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 14•20 years ago
|
||
My company needed this feature so here's what I've done to
enable qa-contacts in the enter_bug form. Note that this depends on
the default-cc patches from bug #38922. That is, it auto-fills the
qa-contact field based on the component you select, but if you
manually enter a qa-contact, it'll leave it alone.
My company is using 2.18 but have confirmed the patch also works in
2.19.
Comment 15•20 years ago
|
||
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged
enhancement that hasn't already landed is being pushed out. If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee | ||
Comment 16•20 years ago
|
||
Here's a patch that doesn't require anything else to land first. Pretty
straightforward, actually... or maybe it just feels that way after all my
studying of this template to implement clone bug. :)
(Albert, I noticed that you didn't change enter_bug or post_bug at all. For the
former, I believe that means that QA Contact won't be saved through
bookmarkable templates; for the latter, I'm not sure that a modified QA Contact
would be saved at all -- the default would always be pulled from the DB!)
Assignee | ||
Updated•20 years ago
|
Assignee: myk → travis
Attachment #155894 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #174419 -
Flags: review?
Assignee | ||
Updated•20 years ago
|
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Comment 17•20 years ago
|
||
Comment on attachment 174419 [details] [diff] [review]
Code patch for tip
>+SendSQL("SELECT name, description, initialowner, initialqacontact
>+ FROM components
>+ WHERE product_id = $product_id
>+ ORDER BY name");
> while (MoreSQLData()) {
>- my ($name, $description, $login, $realname) = FetchSQLData();
>+ my ($name, $description, $owner, $qacontact) = FetchSQLData();
>
> push @components, {
> name => $name,
> description => $description,
>- default_login => $login,
>- default_realname => $realname,
>+ initialowner => DBID_to_name($owner),
>+ initialqacontact => DBID_to_name($qacontact),
> };
> }
An error message is displayed if the QA contact is not defined: "The name
__UNKNOWN__ is not a valid username. Either you misspelled it, or the person
has not registered for a Bugzilla account."
Before calling DBID_to_name(), you should be sure that $owner, respectively
$qacontact, is non-zero. A better way to do these both steps into a single one
is to do something like this:
"SELECT name, description, p1.login_name, case when initialqacontact>0 then
p2.login_name else '' end FROM components, profiles p1, profiles p2 where
p1.userid=initialowner and case when initialqacontact>0 then
p2.userid=initialqacontact else 1=1 end ORDER BY name".
This way, you don't need to call DBID_to_name() and an empty string is returned
if the initial QA contact is not defined.
Moreover, please use Bugzilla->dbh stuff instead of SendSQL(). ;)
>+ my $qa_contact;
>+ if ($::FORM{'assigned_to'} eq "") {
>+ SendSQL("SELECT initialqacontact FROM components " .
>+ "WHERE id = $component_id");
>+ $qa_contact = FetchOneColumn();
>+ } else {
>+ $qa_contact = DBNameToIdAndCheck(trim($::FORM{'qa_contact'}));
>+ }
I think if (trim($::FORM{'assigned_to'}) eq "") is better. Moreover, please use
$cgi->param() instead of $::FORM{}.
>+[% IF Param("useqacontact") %]
>+ <tr>
>+ <td align="right"><strong>QA Contact:</strong></td>
>+ <td colspan="3">
>+ [% INCLUDE global/userselect.html.tmpl
>+ name => "qa_contact"
>+ value => qa_contact
>+ disabled => qa_contact_disabled
>+ size => 32
>+ emptyok => 1
>+ %]
>+ <noscript>(Leave blank to assign to default qa contact)</noscript>
>+ </td>
>+ </tr>
>+[% END %]
>+
> <tr>
> <td align="right"><strong>URL:</strong></td>
> <td colspan="3">
IMHO, the QA contact field should be just below the "Assign To" field instead
of being between the "Deadline" and "URL" fields.
I did not go through all the code so there may be some other issues.
Attachment #174419 -
Flags: review? → review-
Assignee | ||
Comment 18•20 years ago
|
||
Fixed, as per comments and IRC discussion.
Attachment #174419 -
Attachment is obsolete: true
Attachment #174526 -
Flags: review?(LpSolit)
Assignee | ||
Comment 19•20 years ago
|
||
SQL breakthrough; new patch.
Attachment #174526 -
Attachment is obsolete: true
Attachment #174528 -
Flags: review?(LpSolit)
Assignee | ||
Updated•20 years ago
|
Attachment #174526 -
Flags: review?(LpSolit)
Assignee | ||
Updated•20 years ago
|
Attachment #174528 -
Flags: review?(justdave)
Assignee | ||
Updated•20 years ago
|
Attachment #174528 -
Flags: review?(justdave)
Attachment #174528 -
Flags: review?(LpSolit)
Assignee | ||
Comment 20•20 years ago
|
||
Fixed, as per IRC review
Attachment #174528 -
Attachment is obsolete: true
Attachment #175075 -
Flags: review?(LpSolit)
Assignee | ||
Comment 21•20 years ago
|
||
Oops... in addition to too much patch, introduced a new bug into v4. Here's a
cleaned up patch for v5 with just the stuff it should have.
Attachment #175075 -
Attachment is obsolete: true
Attachment #175077 -
Flags: review?(LpSolit)
Assignee | ||
Updated•20 years ago
|
Attachment #175075 -
Flags: review?(LpSolit)
Comment 22•20 years ago
|
||
Comment on attachment 175077 [details] [diff] [review]
Code patch for tip, take 5
> [%- END %]
>-var last_default_owner;
> function set_assign_to() {
Please leave an empty line before the function declaration.
> var form = document.Create;
> var assigned_to = form.assigned_to.value;
>+ var qa_contact = form.qa_contact.value;
If Param("useqacontact") is 0, form.qa_contact is not defined and the JS script
stops working. You have to put var qa_contact = form.qa_contact.value; in a [%
IF Param("useqacontact") %] [% END %].
Else it's good, and all my comments in IRC have been reported, so next patch
will be the final one. ;)
Attachment #175077 -
Flags: review?(LpSolit) → review-
Assignee | ||
Comment 23•20 years ago
|
||
Fixed as per comments above.
Attachment #175077 -
Attachment is obsolete: true
Attachment #175150 -
Flags: review?(LpSolit)
Comment 24•20 years ago
|
||
I haven't installed/played with this patch, but does this not have the potential
to 'break' sites that use QA-Contact for 'component watching'? In other words,
if someone who doesn't necessarily know what they're doing opens a ticket and
provides a non-default QA-contact that isn't on people's watchlists, is it going
to fail to notify people who think they'll be notified because they're watching
the default QA-Contact?
It seems dumb to not provide this patch based solely on that concern, but it
also seems not-to-smart to break admittedly 'kludgey' functionality that we know
is being used by alot of sites (b.m.o. included).
Assignee | ||
Comment 25•20 years ago
|
||
(In reply to comment #24)
> does this not have the potential
> to 'break' sites that use QA-Contact for 'component watching'?
It does. In fact, it would break my own site, as we use QA for the Design
Authority field, which is set at the component level and is never changed
throughout the life of the bug.
HOWEVER... the fix for this is completely trivial.
--- create.html.tmpl 2005-02-22 10:36:26.143706179 -0600
+++ create.html.tmpl.qa_disabled 2005-02-22 10:36:43.407063575 -0600
@@ -233,7 +233,7 @@
[% INCLUDE global/userselect.html.tmpl
name => "qa_contact"
value => qa_contact
- disabled => qa_contact_disabled
+ disabled => 1
size => 32
emptyok => 1
%]
Apply that patch, and the QA field still shows up on enter_bug.cgi, and still
changes to be appropriate to the component, but is also disabled from user
modification.
This is what I'll be doing locally, and since it takes place in a template file
it is an easy change for local Bugzilla admins to make too. You raise a valid
point, however, and this probably shouldn't be added without letting people
know how to disable it, so I've added the 'relnote' keyword to facilitate
getting the message out.
Keywords: relnote
Comment 26•20 years ago
|
||
Comment on attachment 175150 [details] [diff] [review]
Code patch for tip, take 6
Nice work! r=LpSolit
Attachment #175150 -
Flags: review?(LpSolit) → review+
Updated•20 years ago
|
Flags: approval?
Updated•20 years ago
|
Flags: documentation?
Flags: approval?
Flags: approval+
Assignee | ||
Comment 27•20 years ago
|
||
Checking in enter_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v <-- enter_bug.cgi
new revision: 1.107; previous revision: 1.106
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v <-- post_bug.cgi
new revision: 1.103; previous revision: 1.102
done
Checking in template/en/default/bug/create/create.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tm
pl,v <-- create.html.tmpl
new revision: 1.47; previous revision: 1.46
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: [people:qa] enter_bug
Comment 29•18 years ago
|
||
There is no specific place with fields available on bug creation. So I only updated the "Anatomy of a Bug" section where the QA contact field was missing.
Attachment #246085 -
Flags: review?(documentation)
Comment 30•18 years ago
|
||
Attachment #246085 -
Attachment is obsolete: true
Attachment #246225 -
Flags: review?(documentation)
Attachment #246085 -
Flags: review?(documentation)
Updated•18 years ago
|
Attachment #246225 -
Flags: review?(documentation) → review+
Updated•18 years ago
|
Attachment #246225 -
Flags: review+ → review?
Updated•18 years ago
|
Attachment #246225 -
Flags: review? → review+
Comment 31•18 years ago
|
||
tip:
Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml
new revision: 1.52; previous revision: 1.51
done
2.22.1:
Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml
new revision: 1.37.2.11; previous revision: 1.37.2.10
done
2.20.3:
Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml
new revision: 1.33.2.15; previous revision: 1.33.2.14
done
Flags: documentation?
Flags: documentation2.22+
Flags: documentation2.20+
Flags: documentation+
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•