133559 - Bugzilla Helper should be enter_bug.cgi template

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect, P3)

Description

[Gervase Markham [:gerv]]

Bugzilla Helper should be a "simple bug entry form" mozilla.org-specific
template for enter_bug.cgi. Now that enter_bug.cgi has been templatised, this
should be quite simple.

Gerv

Comment 1

[Gervase Markham [:gerv]]

I have this nearly done; but it depends on a few mods to Bugzilla's core over in
bug 137229, and also will be affected by the change in bug 138904.

Gerv

Comment 2

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Here we are. Using the hooks I put in earlier, we can now have a two-file
drop-in Bugzilla Helper replacement.

This copy is unashamedly mozilla-org specific. We need to decide whether it
ships as-is as part of Bugzilla, or whether it has to be generified. We don't
have to decide that immediately; I'm putting this up for review so people can
give it a look over, and it can be ready to drop into b.m.o when they upgrade.

Comment 3

[Gervase Markham [:gerv]]

myk: I'd appreciate it if you gave this the once over, and had a play with it.

Gerv

Comment 4

[Gervase Markham [:gerv]]

Attachment: Patch v.2

Enhanced; also added mozilla-org specific link to page about why we require
accounts, which uses the mechanism outlined in bug 143650.

Gerv

Comment 5

[Matthew Tuck [:CodeMachine]]

Yes this should definitely be generalised I can see installations wanting this.

Comment 6

[Gervase Markham [:gerv]]

Note to self: include RESOLVED but not VERIFIED bugs in searches to make it
possible to catch recently-closed bugs. Tip from Bryce Nesbitt.

Gerv

Comment 7

[Gervase Markham [:gerv]]

Attachment: Simple search tool by Bindu Sharma - for ideas

Comment 8

[Gervase Markham [:gerv]]

Attachment: HTML file to drive said tool

Comment 9

[Gervase Markham [:gerv]]

Attachment: Patch v.3

This patch contains solely the two files necessary to add another format to
enter_bug.cgi - the template for the enter_bug page, and the one to format the
initial comment. These files are currently mozilla.org-specific.

Adding these to an existing Bugzilla information should be zero-risk - it's
just another way of presenting information to post_bug.cgi, which should do all
the relevant sanity-checking of input data anyway.

Still, a review can't hurt :-) I'd particularly like to know how it performs in
different browsers. I've tested Mozilla, NS 4.7x and Konqueror on Linux. Konq
has problems with the <iframe> width, calculating it from the viewport rather
than from inside the <blockquote>. But that's not too bad.

Gerv

Comment 10

[Gervase Markham [:gerv]]

Changing severity to indicate this bug's importance.

Gerv

Comment 11

[Myk Melez [:myk] [@mykmelez]]

General Comments:

1. There should be some info here about getting an account if necessary?
2. I can't help thinking the field descriptions should be tooltips or be
   on top of the field (even though that means the field names and fields
   aren't aligned).


+    Bugzilla are duplicates, and this means a lot of wasted effort on
+    the part of our QA engineers.

Nit: "and this wastes a lot of our QA engineers' time"


+      Visit the <a href="duplicates.cgi">most-frequently-reported bugs page</a>
+      and see if your bug is there. If not, go to the
+      <a href="query.cgi">search page</a> and search Bugzilla by entering two or
+      three of the main words having to do with your bug in the top box. 
+      For example: <tt><b>crash mail</b></tt> or <tt><b>copy paste</b></tt>.

This should be linked directly to the new query page if that's the one you want
users to use: "query.cgi?format=modern" or something like that (will be known
after the upgrade tonight).


+    </p> 
+  [% ELSE %]
+    <p>
+    Check the list of most-frequently-filed bugs below. 
+    If your bug's not there, then search Bugzilla by entering two or 

"bug isn't there, search"


+      <b>Product</b>
+    </td>
+    <td valign="top">
+      <input type="hidden" name="product" value="[% product FILTER html %]">
+      [% product FILTER html %]

You might consider overriding product as well, since there are a ton of
components in Browser that no newbie will ever know to file a bug in.  Perhaps
there should be an "is_internal" or "is_pro" flag on products that shouldn't be
shown to users who haven't said they are engineers.


+            <span id="description"></span>

This span should have a set size; otherwise the form jumps around when you
select a component with a long description.  Also, the description should be set
apart from the form in some way: different font size or color, background color,
border, etc.


+      using the "Create Attachment" link after the bug is filed.

I think it says something else at the moment.


+          Critical: Mozilla crashes, hangs, leaks memory, or causes you to 

I don't think most newbies will know what leaking memory is.


+      How big the problem is. Also, if your bug is a request for a new feature

"serious the problem is"

Comment 12

[Gervase Markham [:gerv]]

> 1. There should be some info here about getting an account if necessary?

You can't get this far without one. The solution to this is to have a link on
the "get an account" page that you get when you try and do something without
logging in, called "Why do I need an account?"

> 2. I can't help thinking the field descriptions should be tooltips or be
>    on top of the field (even though that means the field names and fields
>   aren't aligned).

Having them only as tooltips would definitely be a usability regression. Having
them on top would make the page appear even longer than it actually is, which is
something I really want to avoid.

> You might consider overriding product as well, since there are a ton of
> components in Browser that no newbie will ever know to file a bug in.  Perhaps
> there should be an "is_internal" or "is_pro" flag on products that shouldn't be
> shown to users who haven't said they are engineers.

The correct solution here is to have a "simple" format for the product list,
which is hard-coded to the obvious products rather than auto-generated. Then,
you will have selected the correct product by the time you get here.

Other than those discussed above, I'll make all the changes you suggest.

Gerv

Comment 13

[Gervase Markham [:gerv]]

The current version of this patch is up on b.m.o; but I won't publicise the
location and ask people to test it until duplicates.cgi is fixed (bug 151281).

Gerv

Comment 14

[Gervase Markham [:gerv]]

Myk:
> This span should have a set size; otherwise the form jumps around when you
> select a component with a long description

I haven't quite figured out how to do this. Whatever I do, a long description
still rearranges the page. Any hints?

Gerv

Comment 15

[Gervase Markham [:gerv]]

Attachment: Patch v.4

Here's a new version, incorporating a lot of the feedback given in the
newsgroups and this bug. Currently open issues:

- the component <span> needs a size
- the duplicates simple format needs a heading (another bug)
- the product list needs simplifying (another bug)
- Should use Quicksearch instead of the current allwordssubstr
- Change index.html.tmpl to better present the two versions correctly

Gerv

Comment 16

[Myk Melez [:myk] [@mykmelez]]

>I haven't quite figured out how to do this. Whatever I do, a long description
>still rearranges the page. Any hints?

You may need to use a block-level element like a div instead and then set the
width and height properties to an absolute value and "overflow: scroll" so
content that cannot fit in the area can be scrolled through.

Comment 17

[Gervase Markham [:gerv]]

[CCing Hixie: he can probably solve my problem in an instant.]

> You may need to use a block-level element like a div instead and then set the
> width and height properties to an absolute value and "overflow: scroll" so
> content that cannot fit in the area can be scrolled through.

overflow: scroll always adds scrollbars, which is ugly. overflow:auto adds a
vertical scrollbar only when necessary, which seems the right thing. And I can
set the height with no problem (to 5em.) However, I can't get the width to work.
No width means the div begins as the width of its contents ("Select a component
to see its description") and remains that width. What I want is for it to start
as the width of the _window_. width=100% does not do this, and I don't know why.
The only thing I can find that makes it work is to have the initial text longer
than one window-width. And that's a horrible hack.

Any ideas?

Gerv

Comment 18

[Gervase Markham [:gerv]]

Attachment: Patch v.5

Now uses QuickSearch, and gets some way to getting the Components descriptions
right. Myk - please upload this version.

Gerv

Comment 19

[Myk Melez [:myk] [@mykmelez]]

Can this patch be placed on landfill first so I have a chance to see it in action?

Comment 20

[Gervase Markham [:gerv]]

Attachment: Patch v.6

Fixes search to use format=simple again, and puts descriptions above fields for
clarity (requested by myk.)

Gerv

Comment 21

[Gervase Markham [:gerv]]

Patch v.6 is slightly broken. Never mind. Try out the fixed version here:
http://landfill.tequilarista.org/bz133559/enter_bug.cgi?format=guided

Gerv

Comment 22

[Myk Melez [:myk] [@mykmelez]]

I get the error "A legal OS/Version was not set." when I use the Bugzilla Helper
test install and select the "Macintosh" platform and "Mac System 9.x" operating
system.

Comment 23

[Gervase Markham [:gerv]]

I don't see that problem on my local copy (and landfill is down.) But it could
be because some of the OS names are hard-coded to match b.m.o, whose OS list is
not quite the same as the default.

If you have no other issues, it would be great if you could overwrite the
current test version on b.m.o with the new test version, so we can try it out in
situ.

Gerv

Comment 24

[Myk Melez [:myk] [@mykmelez]]

I'll put the latest version up on the live Bugzilla test on mothra.  Landfill is
down now, however, and patch v.6 is broken according to comment 21.  Can you
attach the latest version?

Comment 25

[Gervase Markham [:gerv]]

Attachment: Patch v.7

Latest and greatest, for Myk to put up.

Gerv

Comment 26

[Gervase Markham [:gerv]]

Oh, and what's the URL of the live Bugzilla test on Mothra?

Gerv

Comment 27

[Myk Melez [:myk] [@mykmelez]]

It's up.

http://mothra.mozilla.org/webtools/bugzilla-test/

Comment 28

[Gervase Markham [:gerv]]

OK, I've spotted and (I think) fixed the: "The /guided/ output format is not
supported by this script" error on filing a bug; this was caused by a bmo
customisation. I've also reworded a few bits. But other than that, I'm happy
with it. Would someone else care to bang on it a bit? I'll post to the NGs again.

Gerv

Comment 29

[Gervase Markham [:gerv]]

Attachment: Patch v.8

This has all the fixes from feedback in, and is ready to go up on b.m.o proper
and take over from the Bugzilla Helper.

Gerv

Comment 30

[Gervase Markham [:gerv]]

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

Comment 31

[Gervase Markham [:gerv]]

Note to myk: when you do put this up, remember to remove the old "format=simple"
versions of the templates.

Gerv

Comment 32

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 91279 [details] [diff] [review]
Patch v.8

Ok, this looks good. r=myk, and it has been staged at:

http://mothra.mozilla.org/webtools/bugzilla-stage/

Try it out for your next couple of bugs, and if it works fine I'll move it into
production.

Comment 33

[Bradley Baetz (:bbaetz)]

myk - you should move the 'report a bug' link on the index page to point to
that, too

Comment 34

[Myk Melez [:myk] [@mykmelez]]

The helper has been moved into production, the "report a bug" link on the home
page has been pointed to "enter_bug.cgi?format=guided", and the "simple" format
has been removed.

Comment 35

[Gervase Markham [:gerv]]

Yee-ha! :-)

We may check this into Bugzilla CVS as an example of a customisation - we'll see
how it goes. But this bug is definitely fixed. And I'm off to close about 25
Bugzilla Helper bugs. Woohoo!

Gerv