577053 - Upgrading from 2.18 or earlier fails with the new status workflow patch

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect)

Description

[Max Kanat-Alexander]

The Install::DB code doesn't work right for upgrading from 2.18 and earlier anymore, because the bug_status table is *created*, for a 2.18 upgrade, and so it already has the is_open column. Instead, I'm going to check if the NEW status exists, and if it does, then we're upgrading from a version before 4.0 and we need to upgrade the workflow instead of initializing it.

Comment 1

[Max Kanat-Alexander]

Attachment: v1

Here we go. Granting myself review as module owner.

Comment 2

[Max Kanat-Alexander]

This should fix the checksetup tinderbox bustage.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/Install/DB.pm
Committed revision 7280.

Comment 3

[Frédéric Buclin]

Your patch is not safe at all. Some installations probably renamed NEW to something else, e.g. CONFIRMED or VALID or anything else in Bugzilla 3.x.

Comment 4

[Frédéric Buclin]

You should rather look for UNCONFIRMED, which is a hardcoded bug status.

Comment 5

[Frédéric Buclin]

Reopening till comment 3 and 4 are discussed.

Comment 6

[Max Kanat-Alexander]

But UNCONFIRMED exists in both the old and the new workflow, so that wouldn't work. Also, statuses were not, in fact, customizable before Bugzilla 3.2. Changing the name of NEW to something else in the database would have had various odd effects, and would be a customization that the upgrader was aware of.

I was also thinking that I could check for a 4.0-only change, though, like the existence or non-existence of bugs.keywords.

Comment 7

[Frédéric Buclin]

But you can customize bug statuses since 3.2, and in comment 0, you want to know if it's a new installation or an upgrade from a version before 4.0. This leaves us with the 3.2 - 3.6 window, which is problematic. If it's a new installation, all you want to know if whether the status_workflow table is populated, right?

Comment 8

[Max Kanat-Alexander]

(In reply to comment #7)
> But you can customize bug statuses since 3.2, and in comment 0, you want to
> know if it's a new installation or an upgrade from a version before 4.0.

  That's true, more or less. Did the code in that block change between 3.2 and 3.6? It might have...

Comment 9

[Max Kanat-Alexander]

Attachment: Fix, v1

Okay, this is better--we check something about the schema instead. This means that if you have a version of Bugzilla from before bugs_activity.comment_id was added, you will get the old workflow, but that's okay, because that basically means we're upgrading.

Comment 10

[Frédéric Buclin]

Comment on attachment 485434 [details] [diff] [review]
Fix, v1

Hum, yes, this looks safer. r=LpSolit

Comment 11

[Max Kanat-Alexander]

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/                       
modified Bugzilla/Install/DB.pm
Committed revision 7566.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.0/                         
modified Bugzilla/Install/DB.pm
Committed revision 7455.