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.
Created attachment 456137 [details] [diff] [review] v1 Here we go. Granting myself review as module owner.
Assignee: installation → mkanat
Status: NEW → ASSIGNED
Attachment #456137 - Flags: review+
This should fix the checksetup tinderbox bustage. Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/ modified Bugzilla/Install/DB.pm Committed revision 7280.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
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.
You should rather look for UNCONFIRMED, which is a hardcoded bug status.
Reopening till comment 3 and 4 are discussed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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?
(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...
Created attachment 485434 [details] [diff] [review] 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.
Attachment #485434 - Flags: review?(LpSolit)
Comment on attachment 485434 [details] [diff] [review] Fix, v1 Hum, yes, this looks safer. r=LpSolit
Attachment #485434 - Flags: review?(LpSolit) → review+
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.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.