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

RESOLVED FIXED in Bugzilla 4.0

Status

()

--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: mkanat, Assigned: mkanat)

Tracking

Bugzilla 4.0
Bug Flags:
approval +
approval4.0 +
blocking4.0 +

Details

Attachments

(2 attachments)

(Assignee)

Description

8 years ago
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.
(Assignee)

Comment 1

8 years ago
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+
(Assignee)

Comment 2

8 years ago
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

Comment 3

8 years ago
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

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

Comment 5

8 years ago
Reopening till comment 3 and 4 are discussed.
Status: RESOLVED → REOPENED
Flags: blocking4.0+
Resolution: FIXED → ---
(Assignee)

Comment 6

8 years ago
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

8 years ago
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?
(Assignee)

Comment 8

8 years ago
(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...
(Assignee)

Comment 9

8 years ago
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 10

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

Hum, yes, this looks safer. r=LpSolit
Attachment #485434 - Flags: review?(LpSolit) → review+

Updated

8 years ago
Flags: approval?
Flags: approval4.0?
(Assignee)

Updated

8 years ago
Flags: approval?
Flags: approval4.0?
Flags: approval4.0+
Flags: approval+
(Assignee)

Comment 11

8 years ago
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 ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.