Open
Bug 16647
Opened 25 years ago
Updated 5 years ago
should be a status whiteboard field on new bug form
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement, P3)
Bugzilla
Creating/Changing Bugs
Tracking
()
NEW
People
(Reporter: dbaron, Unassigned)
References
(Depends on 1 open bug, )
Details
(Whiteboard: [blocker will fix])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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•25 years ago
|
Severity: normal → enhancement
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.
Reporter | ||
Comment 2•25 years ago
|
||
Piling too many things onto one bug makes them less likely to be fixed.
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.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
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.
Reporter | ||
Updated•25 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•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.
Comment 6•25 years ago
|
||
Reassigning to cbegle, who owns that new form.
Assignee: terry → cbegle
Status: REOPENED → NEW
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.
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.
Reporter | ||
Comment 9•25 years ago
|
||
OK... so what's the point of leaving this bug open?
Comment 10•25 years ago
|
||
Keywords field on submit now primarily covered at bug #25521.
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.
Comment 12•24 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.
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.
Updated•24 years ago
|
QA Contact: matty
Comment 14•23 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. ;)
No longer blocks: 86547
Comment 15•23 years ago
|
||
I've put a patch for this on bug #25521.
Target Milestone: --- → Bugzilla 2.16
Updated•23 years ago
|
Priority: P3 → P5
Updated•23 years ago
|
Priority: P5 → P2
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.
Depends on: 25521
Updated•23 years ago
|
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Comment 17•23 years ago
|
||
Reassigning to default owner.
Updated•23 years ago
|
Whiteboard: enter_bug
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
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.
Summary: should be a status whiteboard and/or keyword field on new bug form → should be a status whiteboard field on new bug form
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
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.
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)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
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"....
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago → 20 years ago
Resolution: --- → WONTFIX
Updated•20 years ago
|
Target Milestone: Bugzilla 2.20 → ---
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
Attachment #196213 -
Flags: review?
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
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Attachment #196213 -
Flags: review? → review-
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.
Attachment #196213 -
Attachment is obsolete: true
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 31•18 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•18 years ago
|
Priority: P2 → P3
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
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.
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.
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?
Updated•14 years ago
|
Flags: approval?
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.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
Updated•10 years ago
|
Target Milestone: Bugzilla 5.0 → ---
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].
You need to log in
before you can comment on or make changes to this bug.
Description
•