Bugzilla Tips (X): Triage helper tools: Greasemonkey scripts

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

If you read a lot of Bugzilla tickets per day you run into some recurring situations. For example, a bug report might miss sufficient information and you want to point its reporter to a wikipage which explains how to write good bug reports, or you clean up older rotting tickets without enough information and while closing them you want to explain to the reporter why you close the report.

In such situations, having some one-click stock answers (or “canned responses” as others call them) can come in handy in order to save time. I’ve been using several Greasemonkey scripts in my Firefox browser over those years. The two Javascript files which I use in Wikimedia Bugzilla are available to everybody in the code repository. They can be checked out by running the command git clone https://gerrit.wikimedia.org/r/p/wikimedia/bugzilla/triagescripts.git
To use them in Firefox, one has to install Greasemonkey, visit the Git web interface of the repository with Firefox and click the “Raw” links. An installation dialog will open. Note that these scripts only work if you have canconfirm and editbugs permissions in Bugzilla.

This is how it looks after installing the scripts:

bugzilla-triagehelpers-stockanswers

In the picture above, I clicked the “[Close:WorksForMe]” answer. An explanatory command (which also automatically picks up the name of the reporter) is added and the status “RESOLVED WORKSFORME” is set.

As time goes by I’ve added more functionality for my convenience, mostly links to places which are related to functionality exposed in the Bugzilla interface:

bugzilla-triagehelpers

Most useful to me is

  • coloring reporters based on their email addresses (I might spend less attention on a report created by an established developer or employee than a newcomer),
  • coloring the component (MediaWiki has hundreds of extensions, and extensions which are deployed on Wikimedia servers might receive more attention than a non-deployed 3rd party extension),
  • a link to search for other reports created by the same user, and
  • a link to a graph of the priority distribution of tickets for the component (to check how realistically priorities are set – if you only have open tickets with high priority for your component, then something is wrong).

While the code of these Greasemonkey scripts would welcome some cleanup and refactoring, it works for me. Plus today I finally introduced a bunch of boolean variables at the top of the scripts so users can easily define which functionality s/he wants to enable (or not). You are welcome to give it a try (and provide patches if you feel like hacking away).

Of course all this functionality could also be added to the Bugzilla code on the server but I do not want to clutter the Bugzilla user interface even more for everybody by default.
Note that there is also a “proper” upstream Bugzilla extension called Canned Comments available since May 2012 which I have not played with yet.

4 Responses to “Bugzilla Tips (X): Triage helper tools: Greasemonkey scripts”

  1. Sindhu says:

    This is so useful, thanks!

  2. aklapper says:

    Okay, I admit that “these scripts only work if you have canconfirm and editbugs permissions in Bugzilla” is a lie now that I’ve hacked a bit more on the code. Still, some stuff will not work (but it shouldn’t trigger ugly errors in the Javascript console of your browser anymore).

  3. Matma Rex says:

    Let me share something too, then: a piece of CSS.

    http://pastebin.com/Q2cR9TpF

    It makes the summaries of dependent, blocking and see-also bugs visible on the bug page. Looks like this: http://i.imgur.com/RQVv6Yf.png

  4. […] triage helper scripts by providing a setting for each functionality at the beginning of the file; a blog post provides more details. Bugzilla’s testing instance on Wikimedia Labs saw several patches […]

    [WORDPRESS HASHCASH] Snoopy failed to fetch results for the comment blog url (https://blog.wikimedia.org/2013/09/06/engineering-august-2013-report/) with error ” and so is spam.