Batch modifying Bugzilla milestones

One of the love-it-or-hate-it features of Bugzilla is that milestones are per-product and not global, i.e. the “beta” milestone on product A is a completely different entity from the “beta” milestone on product B. This affords extra flexibility, but it’s annoying if you have a lot of products and want to rename or reorder your milestones.

To the best of my knowledge having researched the issue, there is no accepted way to make the same change to multiple milestones at once short of manually modifying the database with SQL. This seems like a misfeature to me.

I’ve had to do some reorganising of our bugzilla and I’m recording here the SQL statements I used. I don’t guarantee that these do the right thing, but everything here appeared to work for my purposes.

Renaming a milestone

Beware that the bugs table references the string name of the milestone, not the milestone ID. If you change the name of a milestone in the milestones table, you must also update the bugs table. You need to be particularly careful if the new name for milestone A is the same as the old name for milestone B, or you will end up with bugs appearing on the wrong milestone. Unless the chain of milestone renames is circular, it ought to work to start by moving all bugs to newly-added names, then moving bugs to the milestone names no longer in use, and so on.

First, rename the milestone in the milestones table:

UPDATE milestones
   SET value = 'New Name'
 WHERE value = 'Old Name';

Then update the bugs that refer to this milestone:

UPDATE bugs
   SET target_milestone = 'New Name'
 WHERE target_milestone = 'Old Name';

Creating a new milestone for all products

Simply do an INSERT … SELECT from the products table:

INSERT 
  INTO milestones
       (product_id, value, sortkey)
SELECT id, 'My New Milestone', <sortkey> 
  FROM products;

Batch-moving to a new milestone

This is relatively easy to do, since the target milestone is a string, and there is no referential integrity to ensure that the string actually exists as a milestone for the appropriate product. On the other hand, it’s very easy to muck up royally for the same reason.

Note that you can’t do this in the UI, since if you include multiple products in your search, the ‘change multiple bugs at once’ feature won’t let you change the milestone.

e.g. to move all low-priority January 2010 bugs to February 2010:

UPDATE bugs
   SET target_milestone = 'February 2010'
 WHERE priority IN ('P3', 'P4', 'P5')
   AND target_milestone = 'January 2010'
   AND bug_status IN ('NEW', 'ASSIGNED', 'REOPENED');

Leave a Reply

Your email address will not be published. Required fields are marked *