Do you use wiki pages to track things? Tired of copy and pasting bugzilla queries and bug information? Me too. I got fed up one day and decided to do something about it and the result is mediawiki-bugzilla.

What is mediawiki-bugzilla?

It is a server-side MediaWiki extension that provides read-only access to the Bugzilla REST API. It’s basically a working proof of concept at this point but I will be beefing it up in the coming weeks.

Why did I write my own MediaWiki extension?

I deal with wiki pages, bugs, and triage daily. It seemed stupid to be copying data and sometimes I wanted to embed up-to-date bug information in various wiki pages. I looked for solutions and found the excellent Bugzilla Reports extension. Unfortunately, it didn’t fit my needs:

  • Bugzilla Reports needs direct access to the Bugzilla database. Yikes! Not only would I not get that access that would mean we would have to security audit the whole thing. Also, it was unclear that the assorted groups and permissions could be preserved across queries
  • The specification/query language was homegrown. In addition to wiki markup one had to take time to learn how to tune and use a specification unique to Bugzilla Reports
  • I’m not the best PHP programmer in the world but the code seemed overly complex and was difficult to dive into

I actually hacked together a proof-of-concept backend to have Bugzilla Reports query the Bugzilla REST API instead of the database but it didn’t work quite right and wasn’t maintainable.

I wanted to make an extension that is painless to use, easy to develop, and has no possible way of exposing restricted bugs. I didn’t want to create my own query specification / format, so I piggybacked off Gerv’s excellent Bugzilla REST API. The extension is basically an easy way to make REST API calls from MediaWiki so the docs can be used for the extension as well.

How to use mediawiki-bugzilla

You essentially use this extension in this way:
[cc lang=’js’]

(JSON REST API query key/value pairs)

[/cc]
For example, the following would be used to get all P1 bugs in the Bugzilla product:
[cc lang=’js’]

{
“product”: “Bugzilla”,
“priority”:”P1″
}

[/cc]

Notice that this is the same example used in the Bugzilla REST API documentation. Any query you can do via the API you should be able to embed in a wiki page using this extension.

I also stubbed out support for charting using the Google Charts API:

[cc lang=’js’]

{
“product”:      “Bugzilla”,
“priority”:     “P1”,
“x_axis_field”: “severity”
}

[/cc]

If you put both of the above examples into a wiki page you get something like this:

I know the tables aren’t styled yet. I’m going to be using jquery UI + the datatable plugin, with a pref to fall back to standard HTML tables without javascript.

All this info (and more!) can be found in the README.

Next steps

The major thing I am going to add is caching of the queries every 5 minutes or so while allowing manual cache overriding. This should make it so 50 people loading a wiki page with 10 queries at the same time doesn’t overwhelm Bugzilla.

After that I will beef up the charting and add some docs. Then we’ll get this rolled out on wiki.mozilla.org!

As always, patches welcome. The code is very simple and it should be very easy to add new features as there aren’t really any right now.

Tagged with: