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!

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

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

*** Bug 27384 has been marked as a duplicate of this bug. ***

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

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

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.

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.

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 .)

Updating QA Contact

*** 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 ]

*** Bug 70268 has been marked as a duplicate of this bug. ***

if i wrote a patch, would it be rejected?

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

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.

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?

*** Bug 95196 has been marked as a duplicate of this bug. ***

moving

*** 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

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.

Anyone who cares about this should feel free to produce a patch for the new templatised version. Gerv

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

>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

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.

*** Bug 140921 has been marked as a duplicate of this bug. ***

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

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.

Moved keyword validity checks before any SQL INSERTs

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

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.

Implements changes and brings up to date to current CVS.

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

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

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.