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)

enhancement

Tracking

()

People

(Reporter: dbaron, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [blocker will fix])

Attachments

(1 file, 1 obsolete file)

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]".
Severity: normal → enhancement
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.
Piling too many things onto one bug makes them less likely to be fixed.
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
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.
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
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.
Reassigning to cbegle, who owns that new form.
Assignee: terry → cbegle
Status: REOPENED → NEW
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.
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.
OK... so what's the point of leaving this bug open?
Keywords field on submit now primarily covered at bug #25521.
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.
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
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
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
Blocks: newbug
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
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
Attached patch simple patch (deleted) — Splinter Review
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
Closed: 25 years ago20 years ago
Resolution: --- → WONTFIX
Target Milestone: Bugzilla 2.20 → ---
Attached patch patch to allow admin to choose (obsolete) (deleted) — Splinter Review
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?
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 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 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
Blocks: 315860
QA Contact: mattyt-bugzilla → default-qa
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
Priority: P2 → P3
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.
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?
Flags: approval?
Flags: approval?
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
Target Milestone: Bugzilla 5.0 → ---
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.

Attachment

General

Creator:
Created:
Updated:
Size: