Keyword field in new bug entry

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
Creating/Changing Bugs
P2
normal
RESOLVED FIXED
18 years ago
5 years ago

People

(Reporter: leger, Assigned: Jeff Hedlund)

Tracking

(Blocks: 1 bug)

2.10
Bugzilla 2.18
Dependency tree / graph

Details

(Whiteboard: enter_bug)

Attachments

(1 attachment, 6 obsolete attachments)

(Reporter)

Description

18 years ago
terry-

Can you make it so the keyword field is available to info entry in the 
http://bugzilla.mozilla.org/enter_bug.cgi page.

This was the eng could add "helpwanted" or whatever when writing the bug. 

thanks!
(Reporter)

Comment 1

18 years ago
terry, more engineers are asking for this, can you do when you get a chance..ok?

Comment 2

18 years ago
The bug entry form is one that we try to keep *simple*.  I am very very
reluctant to add new fields there.

Comment 3

18 years ago
*** Bug 27384 has been marked as a duplicate of this bug. ***
*** Bug 28345 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
*** Bug 28345 has been marked as a duplicate of this bug. ***

Comment 6

18 years ago
In bug 28345, I suggested that the Keywords field be available when reporting a 
new bug, but only for those users who have change-all-aspects-of-any-bug 
permissions. That way, engineers and QA people get access to the field, and 
novice bug reporters don't. Problem solved.
This is really a feature regression over description/whiteboard flags, so I
wouldn't describe it as a new field as such.

Comment 8

18 years ago
Adding a crasher bug without being able to mark it as such in the keywords at 
the first pass is *really* hard. I agree do not add it to the new form to keep 
it simple, but add it to the advanced form (or have it only when reporter has 
"advanced" rights)
See the super dooper new bug #31144 for a proposal which would allow this and
more.

Comment 10

17 years ago
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
(Reporter)

Comment 11

17 years ago
Updating QA Contact
QA Contact: matty

Comment 12

17 years ago
*** Bug 40752 has been marked as a duplicate of this bug. ***
I don't particularly see why we can't add stuff to the new bug entry like so:

New Bug Entry

.... beginner stuff ...

[ Submit Bug ]

----- Anything below this line is optional and can be ignored by novice Bugzilla
users. -----

.... advanced stuff .....

[ Submit Bug ]

Updated

17 years ago
Blocks: 65965
*** Bug 70268 has been marked as a duplicate of this bug. ***

Comment 15

17 years ago
if i wrote a patch, would it be rejected?
Keywords: helpwanted
OS: Windows 95 → All
Hardware: PC → All

Comment 16

16 years ago
Created attachment 27144 [details] [diff] [review]
unified diff against bugzilla TOT implementing keywords on the bug entry page

Comment 17

16 years ago
cool. hrm, can we have someone research the pro/cons of using a multiselect 
listbox instead of an edit field?

Updated

16 years ago
Keywords: helpwanted → approval, patch, review
Personally, I wouldn't approve this patch without creating a new advanced entry
section that newbies don't have to worry about, as I have outlined.  We have
various fields that people want to add here as well.  We could probably move the
assignee into this section as well.

I have two problems with a listbox.  Firstly, on an installation with lots of
keywords, it's really hard to see what has been selected (you might not be sure
what you did if you lose your way).  And secondly, it's inconsistent with the
bug page.
Target Milestone: --- → Bugzilla 2.16
Blocks: 86547
OK, I'm about to attach my proposed patch for this, separating the enter_bug
page into two halves.  I'm not an experienced Bugzilla coder, so beware:

My indentation is probably backwards.
If I kept the table tags balanced it's a minor miracle.
The button list is repeated but is not in a Sub.  Same with some keyword code in
post_bug.cgi lifted from process_bug.cgi.
The layout is probably wrong with certain combinations of fields on.
You may disagree about what should be in the "advanced" section.
We may want to add an option such that certain installations would not get the
message indicating that bug reporters can ignore the advanced section, for
example if all of their users are well trained.
And let's not forget it will fry your hard drive.

So in summary, if you put this patch on your production system, you're likely to
get what you deserve, mmkay?
Created attachment 39797 [details] [diff] [review]
Rough patch.
Priority: P3 → P2
Blocks: 16647
*** Bug 95196 has been marked as a duplicate of this bug. ***

Comment 22

16 years ago
moving
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10

Updated

16 years ago
Whiteboard: enter_bug

Comment 23

16 years ago
*** Bug 99567 has been marked as a duplicate of this bug. ***
I'm templatising enter_bug.cgi. I may be able to do this at the same time.

Gerv

Updated

16 years ago
Depends on: 103953
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
Anyone who cares about this should feel free to produce a patch for the new
templatised version.

Gerv
Keywords: approval, patch, review
(Assignee)

Comment 27

16 years ago
Created attachment 70967 [details] [diff] [review]
patch v.3

Updated patch as requested from Gerv.

I did not add "status whiteboard" to the bug entry as "Rough Patch" did, since
that doesn't seem to be a part of this bug.
     $zz = @::legal_severity;
+        $zz = @::legal_keywords;
     $zz = %::target_milestone;

Is this an evil tab? :-)
Comment on attachment 70967 [details] [diff] [review]
patch v.3

>+# cut & paste from process_bug, better to reuse somehow?

No - because it's going to be different. See below :-)

>+my @keywordlist;
>+my %keywordseen;
>+
>+if ($::FORM{'keywords'}) {
>+  foreach my $keyword (split(/[\s,]+/, $::FORM{'keywords'})) {
>+    if ($keyword eq '') {
>+	   next;
>+	 }
>+	 my $i = GetKeywordIdFromName($keyword);
>+	 if (!$i) {
>+	   PuntTryAgain("Unknown keyword named <code>" .
>+	   				  html_quote($keyword) . "</code>. " .
>+	                 "<P>The legal keyword names are " .
>+				        "<A HREF=describekeywords.cgi>" .
>+				        "listed here</A>.");

I think that, for entering bugs, we should just silently ignore keywords which
aren't keywords. This is much nicer behaviour than slapping the user round the
face with their lack of knowledge. You see, I can see people filling this in
with "helpful" key words about their problem, which Bugzilla won't recognise
most of.

>+    }
>+	 if (!$keywordseen{$i}) {
>+	   push(@keywordlist, $i);
>+	   $keywordseen{$i} = 1;

You make @keywordlist, and never use it. You only need %keywordseen.

>+foreach my $keyword (keys %keywordseen) {
>+	 SendSQL("insert into keywords (bug_id, keywordid) values ($id, $keyword)");

Nit: please capitalise MySQL keywords - it makes the SQL easier to read.

Gerv
Attachment #70967 - Flags: review-
>I think that, for entering bugs, we should just silently ignore keywords which
>aren't keywords. This is much nicer behaviour than slapping the user round the
>face with their lack of knowledge. You see, I can see people filling this in
>with "helpful" key words about their problem, which Bugzilla won't recognise
>most of.

I disagree. Typo's happen, + you get the problem of people typing stuff in, and
it magically vanishing. You can't change keywords unless you have editbugs, so
just require it for this, too. See mpt's comment #6.
Mpt is right - please implement his solution :-) A good name for the template
variable is "canedit".

Gerv
(Assignee)

Comment 32

16 years ago
Created attachment 71286 [details] [diff] [review]
Patch v.4

removed the evil tab
user must be in 'editbugs' group
this patch also includes patch from bug 127318 to enable the above fix
other code cleanup as suggested
Reassigning to patch author.
Assignee: myk → jeff.hedlund
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED

Comment 34

15 years ago
*** Bug 140921 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 35

15 years ago
Created attachment 93446 [details] [diff] [review]
patch v.5

New patch for against the tip, should work fine patching against 2.16 as well.
(Assignee)

Updated

15 years ago
Attachment #70967 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #71286 - Attachment is obsolete: true
Comment on attachment 93446 [details] [diff] [review]
patch v.5

If an invalid keyword is entered, then bits of the bug will be submitted anyway
- see bug 154036.

You need to move the checks up higher in the routine.
Attachment #93446 - Flags: review-
(Assignee)

Comment 37

15 years ago
Created attachment 93569 [details] [diff] [review]
patch v.6

Moved keyword validity checks before any SQL INSERTs
Attachment #27144 - Attachment is obsolete: true
Attachment #39797 - Attachment is obsolete: true
Attachment #93446 - Attachment is obsolete: true
Comment on attachment 93569 [details] [diff] [review]
patch v.6

>+# Check for valid keywords and create list of keywords to be added to db
>+# (validity routine copied from process_bug.cgi)

Can we not factor this out, then?

>+my @keywordlist;
>+my %keywordseen;
>+
>+if ($::FORM{'keywords'}) {
>+    foreach my $keyword (split(/[\s,]+/, $::FORM{'keywords'})) {
>+        if ($keyword eq '') {
>+           next;
>+        }
>+        my $i = GetKeywordIdFromName($keyword);
>+        if (!$i) {
>+            ThrowUserError("Unknown keyword named <code>" . html_quote($keyword)
>+                           .
>+                           "</code>. <p>The legal keyword names are
>+                           <a href=\"describekeywords.cgi\">listed here</a></p>
>+                           .");

Please use the new API for ThrowUserError: 
$vars->{'keyword'} = $keyword;
ThrowUserError("unknown_keyword");
And then put the error in global/messages.html.tmpl .

>+  [% IF UserInGroup('editbugs') %]
>+    <tr>
>+      <td align="right" valign="top">
>+        <strong>
>+          <a href="describekeywords.cgi">Keywords:</a>

Nit: The colon shouldn't be linked.

As it stands, the UI is protected with "editbugs" but the process_bug is not -
so people without this permission could add keywords by hacking the URL.

Gerv
Attachment #93569 - Flags: review-
Factoring out the code really means removing post_bug and using process_bug
instead. Theres not much factoring out which can be done without doing that too
(or having the two files look virtually alike)
bbaetz: is there a plan to combine post_bug and process_bug? Or have some common
module?

Gerv
I want there to be such a plan :) Its a prereq for any sensible working email
bug submission, really.

My point was that that issue shouldn't hold this patch up.

Updated

15 years ago
Blocks: 165025
(Assignee)

Comment 42

15 years ago
Created attachment 98551 [details] [diff] [review]
patch v.7

Implements changes and brings up to date to current CVS.
Attachment #93569 - Attachment is obsolete: true
Comment on attachment 98551 [details] [diff] [review]
patch v.7

2xr=gerv. This needed a "colspan=3" on the <td>, but was otherwise OK.

Gerv
Attachment #98551 - Flags: review+
Fixed. Finally :-)

Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.64; previous revision: 1.63
done
Checking in template/en/default/bug/create/create.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tmpl,v
 <--  create.html.tmpl
new revision: 1.12; previous revision: 1.11
done

Gerv
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 45

14 years ago
I just upgraded our version of Bugzilla from 2.10 to 2.16.3 and I don't see 
this fix in.  Is it supposed to be?  Is there anything I need to do to turn it 
on?
That was fixed in 2.17.1.  You'll need to upgrade again if you want it.
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.