Wow. Bugzilla.
I recently complained that it was obnoxious that I had to upgrade Bugzilla just to be able to search for bugs that had no open blockers. "Gosh," I thought, "Isn't that some of the most important data you could get from you work order system?"
Still, it was more important to get the feature than to complain about it, so I decided to do both. I upgraded our Bugzilla to 2.20 today, only to realize that I had been misled. Version 2.20 made it possible to query for bugs with no blockers, but not to ignore blockers that had been resolved. The crew on the Bugzilla IRC channel seemed to consider this a very complicated feature to implement.
I was worried for my sanity, because I'd just spend half an hour or so looking through some of the uppermost Bugzilla internals, where insane things are done with typeglobs (seemingly because the programmers don't understand the difference between runtime and compile time), do-file, and other sharp and rarely-needed tools. When your application's code (not, say, it's supporting library-building library's code) contains "@::varname" more than two dozen times, you need to stop what you are doing right now.
Anyway, I dove in to try to address this problem, and made several false starts. I finally gave up when I found a hash being stored in an array (and then saw the elements shifted off two-by-two into $key and $value); its keys were eval-able into regex that would match comma-joined tuples of query part descriptions. Its values were coderefs that would alter in-scope lexicals, used as registers, to return values. I felt it would be best to admit defeat and move on, because I was really getting scared.
This evening, though, I put on a brave face and went back into Bugzilla::Search and found a way to do what I wanted. See, Bugzilla searches, these days, are translated into those stringified tuples I mentioned above. The key is to make a tuple that does what you want. The tuples are, if I recall correctly: (name, operator, value). There was no name that corresponded to the query I wanted, so I looked around until I found it. It turned out that they're stored in the fielddefs table. I was feeling good about this, until I realized that the "name" was not just the CGI query parameter used to build the chart, but was actually the column name that would be put into the SQL directly. "bugid" really put "bugid" right there in the SQL. Since there was a "display name" column used to produce the description of the query in the dropdown, all I had to do was create a field named this:
bugs.bug_status NOT IN ('VERIFIED','RESOLVED') AND bugs.bug_id IN (SELECT blocked FROM dependencies WHERE dependson NOT IN (SELECT b2.bug_id FROM bugs b2 WHERE b2.bug_status NOT IN ('VERIFIED','RESOLVED')))
Of course, I had to extend the maximum length of the name field (from 64 characters), but with that done, everything is fine. I tack the above onto my query string, followed by "==0" or something like that, and it works.
Yes. The SQL snippet goes in the query string.
I think I'll go to bed, now, and pray to dream of Cthulhu, and not Bugzilla.
Re:you might be interested in mayfly
rafael on 2005-10-19T11:47:32
Well, if mayfly doesn't fix the serious usability issues with bugzilla's interface, not mentioning the unability to write plugins and so on, I don't think it's worth considering. Have higher goals! Even if your project approaches 10% of RT it will still be much better than the bugzilla abomination.Re:you might be interested in mayfly
TeeJay on 2005-10-19T13:01:18
Mayfly totally replaces the user interface, and will bring in elements of rt (which having used both has plenty of annoyances of its own) and trac, as well as ideas from timesheet and project management applications I have used.
This is why it will break backwards compatibility and require a migration script.
But you do know that bugzilla is trivial to hack on, right? The pages are all TT and the code was simple to modify last time I worked with it.
Re:you might be interested in mayfly
rjbs on 2005-10-19T13:17:43
But you do know that bugzilla is trivial to hack on, right? The pages are all TT and the code was simple to modify last time I worked with it.
I advise anyone considering believing that statement to download Bugzilla and read Bugzilla/Search.pm, checksetup.pl, and buglist.cgi; then try to determine what you need to do to add a searchable and displayable parameter.
Extrapolate that thought, then, to 200 or so source files.Re:you might be interested in mayfly
TeeJay on 2005-10-19T15:49:20
I just replaced the search page with a bunch of more useful summary pages and simpler searches. Wasn't hard at all.
The big search page is scary and horrible and best ignored.Re:you might be interested in mayfly
stu42j on 2005-10-20T19:16:16
I have been thinking about setting up a bug tracker and a support ticket/tracker and have been mentally debating whether or not these two needs should be served by a single application.
I usually think of RT as being more in the support ticket category but obviously it can be used for both (rt.cpan.org). How well, though, does it compare against other tools designed specifically for bug tracking?
Ouch. I knew the hearsay that Bugzilla was terrible, but not that terrible. Small wonder they have security holes to fix at every step and turn.
