Will >> Will's blog

purpose: Will Kahn-Greene's blog of Miro, PyBlosxom, Python, GNU/Linux, random content, PyBlosxom, Miro, and other projects mixed in there ad hoc, half-baked, and with a twist of lemon

Mon, 23 Jun 2014

(Updated) Using the bug_mentor field with the Bugzilla REST API to get mentored bugs

In my previous post, I mentioned how Bugzilla grew a mentor field and had some code on how to query Bugzilla using the old and new APIs for the list of mentored bugs. This updates that information.

Gerv and Byron pointed out there's a isnotempty operator that's better to use than the way I cobbled together to query for bugs that have data in the bug_mentor field.

Thus, the code should look like this:

import requests

# Using the old BzAPI: https://wiki.mozilla.org/Bugzilla:REST_API
r = requests.get(
    'https://api-dev.bugzilla.mozilla.org/latest' +
    '/bug?product=Input&f1=bug_mentor&o1=isnotempty'
)
data = r.json()
print len(data['bugs'])  # Prints 9


# Using the new BMO API. https://wiki.mozilla.org/BMO/REST
r = requests.get(
    'https://bugzilla.mozilla.org/rest' +
    '/bug?product=Input&f1=bug_mentor&o1=isnotempty'
)
data = r.json()
print len(data['bugs'])  # Prints 9

Thu, 19 Jun 2014

Using the bug_mentor field with the Bugzilla REST API to get mentored bugs

Updated June 23rd, 2014:
There's a better way to query the data. See the update blog post

Bugzilla grew a mentor field recently. This is really fantastic as it solves some interesting problems and makes it easier to track various aspects of mentoring which have been previously difficult to track. Yay to everyone involved in making that happen!

Migrating from the old way (sticking [mentor=xxx] in the whiteboard field) to the new way caused a problem that I spent a while working on today. I heard reports of other people having the same problem, hence this blog post.

There are a bunch of Bugzilla-symbiotic systems which would show a list of mentored bugs by checking to see if the string mentor= was in the whiteboard field. That no longer works. Instead we have to check to see if the bug_mentor field is empty. However, this is difficult to express with the old Bugzilla REST API (BzAPI).

The bug_mentor field is unique in that it holds email addresses which have the @ in them. So we can (ab)use this property by seeing if the bug_mentor field contains the @ character.

I did this with the GetInvolved/input.mozilla.org page. Here is the diff in case that's helpful.

Here's some Python that shows this with the old BzAPI and the new BMO API which pulls mentored bugs for Input:

import requests

# Using the old BzAPI: https://wiki.mozilla.org/Bugzilla:REST_API
r = requests.get(
    'https://api-dev.bugzilla.mozilla.org/latest' +
    '/bug?product=Input&bug_mentor_type=contains&bug_mentor=@'
)
data = r.json()
print len(data['bugs'])  # Prints 9


# Using the new BMO API. https://wiki.mozilla.org/BMO/REST
r = requests.get(
    'https://bugzilla.mozilla.org/rest' +
    '/bug?product=Input&bug_mentor_type=substring&bug_mentor=@'
)
data = r.json()
print len(data['bugs'])  # Prints 9

Fri, 18 Jun 2010

Bugzilla scripts: timeline and roadmap

A few years ago, we switched from Trac to Bugzilla. After doing this, we discovered there were some things we really missed about Trac. The first was a unified timeline so that we could see what was going on in the bug tracker. The second was a roadmap that showed us, for a given milestone, where we were at.

I coded up both of these and over the years have made some adjustments. I made the timeline script available a while back, but I don't think I ever made the roadmap script available.

The repository with both of these is at https://git.participatoryculture.org/bugzillascripts/.

They work with our Bugzilla 3.6 instance. I haven't tested either on other versions or other instances.

If you use either or both, send me an email about whether it works for you, bugs, comments, ...