David Baron :dbaron: Reporter
	Description • 25 years ago

There should be a status whiteboard field no the
http://bugzilla.mozilla.org/enter_bug.cgi new bug form.  This would make it
easier to mark appropriate status whiteboards when entering bugs, for example,
"[TESTCASE]".

	Sean Richardson
	Comment 1 • 25 years ago

I agree wholeheartedly (as it is, it's too easy to forget to
add [TESTCASE] to the whiteboard in another pass).

Furthermore...

It would also be nice if Bugzilla could allow an attachment to be created
while adding comments to a bug OR creating a new bug report (this latter would
be a completely new feature) and have createattachment.cgi and enter_bug.cgi
coordinate state so that the notice of the attachment's creation would be held
back from being added to the "Description" filed until the "Additional
Comments" or the original "Description" is added to the bug report, and
so that a "Potential Midair Collision" would not need to be generated if
the reporter/commenter chooses to create the attachment before commiting the
(changes to the) bug report.

Better yet, if a [Refresh] button was added to enter_bug.cgi, it would be
possible to verify that the attachment was created and try it in situ
while finishing up the bug report.

These three changes together would allow for a workflow that would feel more
natural to me: Start writing the bug report; make a testcase; upload the
testcase, refresh, finish writing the report with a chance to refer to the
testcase in the same window for optimum description congruity, and commit.

Or, we could just view the bug report after creating/adding to it, and add
the attachment in a second pass, like we always have. :-(

All three of these are Requests for Enhancement.

	David Baron :dbaron: Reporter
	Comment 2 • 25 years ago

Piling too many things onto one bug makes them less likely to be fixed.

	Sean Richardson
	Comment 3 • 25 years ago

dbaron, you are absolutely correct. Besides, my suggestion is
way too complex for what it buys.

terry, please completely ignore my earlier comment. I was trying to
suggest being able to do 3 things - create a bug report, add an
testcase as an attachment, and add "[TESTCASE]" to the Status Whiteboard -
all before clicking on [Commit]. I don't think that's worth the effort
for the few who would prefer to work that way.

On the other hand, dbaron's RFE has real merit. If the Status Whiteboard
was available to put "[TESTCASE]" in on enter_bug.cgi, all that would
remain to do after commiting would be adding the attachment. As it is,
it is too easy to get distracted and forget to go back to show_bug.cgi
and add to the Whiteboard. There are too many bug reports out there
with testcases and no "[TESTCASE]" in the Whiteboard.

dbaron's RFE should also have the advantage of being very easy to implement.

	Terry Weissman
	Comment 4 • 25 years ago

Sorry, but I think it is more important to keep the enter bug page as simple as
possible, in order to not scare off people who know very little about Bugzilla.

	David Baron :dbaron: Reporter
	Comment 5 • 25 years ago

Since the Bugzilla Helper (or whatever the new form is called...) is now
available, I'm reopening this bug for reconsideration.  Also, I think there
should be a keywords field as well.  Or perhaps *only* a keywords field, since
the keywords field has replaced much of what status whiteboard was for.  I find
myself adding keywords after filing bugs on a significant percentage of the bugs
I'm filing.

	Terry Weissman
	Comment 6 • 25 years ago

Reassigning to cbegle, who owns that new form.

	David Baron :dbaron: Reporter
	Comment 7 • 25 years ago

Does she own the old form too?  I'm saying that now that the new one exists, the
old one can be made more complicated because it's not for inexperienced users
anymore.

	Terry Weissman
	Comment 8 • 25 years ago

No, because Bugzilla exists in more installations than at bugzilla.mozilla.org,
but the new form is only part of bugzilla.mozilla.org.  I don't want to make
more complicated entry pages for all the other installations.

	David Baron :dbaron: Reporter
	Comment 9 • 25 years ago

OK... so what's the point of leaving this bug open?

	Matthew Tuck [:CodeMachine]
	Comment 10 • 25 years ago

Keywords field on submit now primarily covered at bug #25521.

	Christine Begle
	Comment 11 • 25 years ago

fot that bug helper thing, if the enter_bug.cgi script doesn't parse keywords or
status whiteboard stuff, i can't do too much about it.  i'm just riding on top
of whatever is already in the Bugzilla scripts.   if that gets implemented then
i can do something with it.

	Zach Lipton [:zach]
	Comment 12 • 25 years ago

I also feel that the status whiteboard would be a good thing to put on 
enterbug.cgi, but leave it off the bugzilla helper. This way, advanced users 
can use it, but new users can ignore the status whiteboard and keyword 
fields and not be daunted by them.

	Matthew Tuck [:CodeMachine]
	Comment 13 • 24 years ago

We should just separate out all the advanced stuff into a second section and
clearly tell newbies they can ignore it at will.

	Matthew Tuck [:CodeMachine]
	Comment 14 • 24 years ago

Or alternatively have a pref so advanced users can turn on the extra options if
we judge that an "advanced" section is still too confusing for the poor babies
out there.  ;)

	Matthew Tuck [:CodeMachine]
	Comment 15 • 24 years ago

I've put a patch for this on bug #25521.

	Dave Miller [:justdave]
	Comment 16 • 23 years ago

Per Matty's comment, there's a patch for this on bug 25521, this makes this bug
dependent on that one, as this one will be fixed when that one is.

	Andreas Franke (gone)
	Comment 17 • 23 years ago

Reassigning to default owner.

	Andreas Franke (gone)
	Comment 18 • 23 years ago

.

	Dave Miller [:justdave]
	Comment 19 • 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.

	Asa Dotzler [:asa]
	Comment 20 • 22 years ago

fixing summary. keyword in enter_bug is now covered by bug 25521. This bug is
for status whiteboard in enter_bug.cgi

with templatization and the improved bugzilla helper I think we should
reconsider the "enter_bug is for dummys" decisions. 

	Gervase Markham [:gerv]
	Comment 21 • 22 years ago

Keywords is now in (bug 25521). Do we need Status Whiteboard too? It seems to me
that the usual use for this field is to add things as the bug develops, rather
than at the beginning.

Gerv

	Christian Reis
	Comment 22 • 21 years ago

See my recently-posted bug 220183, where I suggest setting the whiteboard in the
post_bug.cgi backend, but not in the UI.

	Dave Miller [:justdave]
	Comment 23 • 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)

	Albert Ting
	Comment 24 • 20 years ago

At my company, we're using this field as a "custom" field until custom field
support has been enabled.  So in that sense, having this field available up
front is beneficial to us.

	Dave Miller [:justdave]
	Comment 25 • 20 years ago

post_bug.cgi already supports this, it's just not in the UI.

And that being the case, I'm happy for this to be a site customization in the
templates.  The new bug form is already crowded enough to scare people.

As noted above, there are lots of sites using Bugzilla, and the guided form is
still Mozilla-specific.

If you want it as a local hack on mozilla.org, that can be done (please file in
mozilla.org/other bmo issues), however, we are still using the standard form for
newbies in a few cases (there is a URL override to get the standard form in
several places that link to it because the guided form wouldn't be appropriate
for the type of bug expected to be filed from that link).

Perhaps we really need a third enter_bug template with a "simple" form that
isn't quite "guided"....

	Todd Stansell
	Comment 26 • 19 years ago

It seems that with the growing use of Bugzilla that this feature should simply
be something that the admin can choose to allow or not on the bug entry page. 
So, this patch allows the administrator to choose whether the status whiteboard
field is displayed on the bug entry page.  This is equivalent to what we did
for the target milestone field in bug 99567.

Todd

	Todd Stansell
	Comment 27 • 19 years ago

Oh, and I'm not allowed to reopen this bug, apparently, so it's still in the
WONTFIX state.  Can someone reopen this for me?

Todd

	Myk Melez [:myk] [@mykmelez]
	Comment 28 • 19 years ago

Todd, I've granted you permissions to make changes to bugs, so you should be
able to reopen bugs now.  Reopening this one myself since I'm here.

	Frédéric Buclin
	Comment 29 • 19 years ago

Comment on attachment 196213 [details] [diff] [review]
patch to allow admin to choose

bitrotten.

Moreover, I don't think we should add a new param for the whiteboard. Only
check whether Param("usestatuswhiteboard") is on, IMO.

	Todd Stansell
	Comment 30 • 19 years ago

Comment on attachment 196213 [details] [diff] [review]
patch to allow admin to choose

This certainly doesn't apply now that defparams.pl is gone. I'd added that
option because it sounded like folks wanted that choice.  If we don't want the
choice, then we can simply use the other simple patch on this bug.

	Frédéric Buclin
	Comment 31 • 18 years ago

This will be fixed by bug 287323, probably in Bugzilla 3.2.

	Max Kanat-Alexander
	Comment 33 • 17 years ago

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

	Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)
	Comment 34 • 16 years ago

I completely agree. Many keywords requires additional info in whiteboard. If an user with editbugs permissions can enter keywords at bug creation, he should be able to change the whiteboard. 
Currently you can change the whiteboard only after bug creation, spamming the bug in this way.

	Tony Mechelynck [:tonymec]
	Comment 36 • 16 years ago

Let's summarize the matter a little.

There are at least two forms for entering bugs. No-privileges users see the "guided" form, which automatically inputs the user's UA, includes separate entries for "Actual results", "Expected results", etc. When I last saw it, this form was a very good training ground to teach users what is expected in a bug report. The present bug is not about that form, even if it could be made even more perfect.

Now that I have acquired editbugs privileges, I see a different form, where almost everything can be set. This form is for supposedly more experienced users, which would not be put off by a plethora of possible settings but on the contrary, by the lack of what they wanted to set on a certain day. This form lacks a "Whiteboard" input box, and (in reply to comment #21) while it is true that the Whiteboard usually changes as a bug develops, and (in reply to comment #0) that there is now a "testcase" keyword which _can_ be set in the "full" bug-creation form, it would IMHO still be useful to be able to fill the Whiteboard right from the start with things like [has workaround], [trunk and 1.8.1 Branch] or even DUPEME.

	Thomas D. (:thomas8)
	Comment 37 • 15 years ago

This bug causes superfluous email traffic on bmo because when posting new bug, it takes a second "commit" just to add the whiteboard comment.
 
Users with editbugs privileges need this on their advanced "new bug" form. Period.
Can this be fixed before this bug gets 10 yrs old?

	Frédéric Buclin
	Comment 38 • 12 years ago

We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.

	Albert Ting
	Comment 39 • 10 years ago

An extension can solve this as well, by creating a bug/create/create-form.html.tmpl hook that includes the extra field noted in attachment 155755 [details] [diff] [review].