If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

should be a status whiteboard field on new bug form

NEW
Unassigned

Status

()

Bugzilla
Creating/Changing Bugs
P3
enhancement
18 years ago
3 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

(Depends on: 1 bug)

Details

(Whiteboard: [blocker will fix], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

18 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]".

Updated

18 years ago
Severity: normal → enhancement

Comment 1

18 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.
(Reporter)

Comment 2

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

Comment 3

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

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 4

18 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.
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: should be a status whiteboard field on new bug form → should be a status whiteboard and/or keyword field on new bug form
(Reporter)

Comment 5

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

Comment 6

18 years ago
Reassigning to cbegle, who owns that new form.
Assignee: terry → cbegle
Status: REOPENED → NEW
(Reporter)

Comment 7

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

Comment 8

18 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.
(Reporter)

Comment 9

18 years ago
OK... so what's the point of leaving this bug open?
Keywords field on submit now primarily covered at bug #25521.

Comment 11

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

Comment 12

17 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.
We should just separate out all the advanced stuff into a second section and
clearly tell newbies they can ignore it at will.
QA Contact: matty
Blocks: 86547
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.  ;)
No longer blocks: 86547
Blocks: 86547
No longer blocks: 86547
I've put a patch for this on bug #25521.
Target Milestone: --- → Bugzilla 2.16
Priority: P3 → P5
Priority: P5 → P2
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.
Depends on: 25521
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Reassigning to default owner.
.
Assignee: cbegle → myk

Updated

16 years ago
Whiteboard: enter_bug
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 20

15 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. 
Summary: should be a status whiteboard and/or keyword field on new bug form → should be a status whiteboard field on new bug form

Updated

15 years ago
Blocks: 165025
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

Comment 22

14 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.
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 24

13 years ago
Created attachment 155755 [details] [diff] [review]
simple patch

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.
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"....
Status: NEW → RESOLVED
Last Resolved: 18 years ago13 years ago
Resolution: --- → WONTFIX
Target Milestone: Bugzilla 2.20 → ---

Comment 26

12 years ago
Created attachment 196213 [details] [diff] [review]
patch to allow admin to choose

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
Attachment #196213 - Flags: review?

Comment 27

12 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
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 29

12 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.
Attachment #196213 - Flags: review? → review-

Comment 30

12 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.
Attachment #196213 - Attachment is obsolete: true

Updated

12 years ago
Blocks: 315860

Updated

11 years ago
QA Contact: mattyt-bugzilla → default-qa

Comment 31

11 years ago
This will be fixed by bug 287323, probably in Bugzilla 3.2.
Assignee: myk → create-and-change
Status: REOPENED → NEW
Depends on: 287323
OS: Other → All
Hardware: Other → All
Whiteboard: enter_bug → [blocker will fix]
Target Milestone: --- → Bugzilla 3.2

Updated

11 years ago
Duplicate of this bug: 371014

Updated

11 years ago
Priority: P2 → P3

Comment 33

10 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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
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.

Updated

9 years ago
Duplicate of this bug: 453011
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.
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?

Updated

7 years ago
Flags: approval?

Updated

7 years ago
Flags: approval?

Comment 38

5 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.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0

Updated

3 years ago
Target Milestone: Bugzilla 5.0 → ---

Comment 39

3 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].
You need to log in before you can comment on or make changes to this bug.