Closed
Bug 85841
Opened 23 years ago
Closed 19 years ago
move fails to correctly set everconfirmed
Categories
(Bugzilla :: Bug Import/Export & Moving, defect, P1)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.22
People
(Reporter: timeless, Assigned: gregaryh)
References
Details
(Whiteboard: blocker will fix)
Attachments
(1 obsolete file)
http://bugzilla.mozilla.org/show_bug.cgi?id=85801 lchiang@netscape.com changed: Status|NEW |UNCONFIRMED <justdave> NEW -> UNCONFIRMED? how did that happen? <Asa> ahh, a moved bug <Asa> so the everconfirmed=1 isn't really moved properly so the first change to the bug in Bugzilla reset it to 0 I think.
Summary: move fails to correctly set → move fails to correctly set everconfirmed
Updated•23 years ago
|
Target Milestone: --- → Bugzilla 2.16
Comment 1•23 years ago
|
||
I'm thinking here that we want to prevent this sort of problem in future. Neither a list of fields to include or a list of fields to exclude seems like the best solution here, because both could result in things going wrong in future when more fields are added. I suggest that we have both an include list and an exclude list. If a field is present and not on either, the code is broken and should fail loudly.
Updated•23 years ago
|
Priority: -- → P1
Updated•23 years ago
|
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: Bugzilla 2.13 → 2.10
Comment 3•23 years ago
|
||
*** Bug 109819 has been marked as a duplicate of this bug. ***
Comment 4•23 years ago
|
||
no patch, not a blocker, 2.16 is now in freeze mode -> 2.18
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 5•22 years ago
|
||
*** Bug 128424 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Component: Bugzilla-General → Bug Import/Export & Moving
Updated•21 years ago
|
Assignee: endico → nobody
Comment 6•20 years ago
|
||
These bugs appear to be abandoned. Retargeting to 2.20
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 7•19 years ago
|
||
I think it would be nice to get this fixed for 2.20.
Assignee | ||
Comment 8•19 years ago
|
||
I have a patch for importxml.pl that fixes this, as well as makes it possible to move attachments with a bug. I will try to get it cleaned up (remove some customizations) for this bug.
Assignee | ||
Comment 9•19 years ago
|
||
This patch addresses a number of issues with importxml.pl, but first let me explain the background of the changes we have made. We have been migrating large numbers of bugs from bugzilla.ximian.com to bugzilla.novell.com (on the order of thousands) so we needed to automate the process a little. importxml.pl works great when you are moving from similar versions of bugzilla, but ximian was running 2.10. Their xml output was not up to date with 2.18 so we took it and transformed each bug's xml using a stylesheet and then ran the import localy using the xml files that were generated. For this we did not want to spam users mail boxes with thousands of emails so I coded a bit that, when set to off, does not send mail. We also wanted to run it as a script from the command line and see any error output there so I added a second bit to do that. In addition to the everconfirmed problem we found and fixed the following: Group permissions on the migrated bugs were not being set correctly. We added code to check which groups the bugs' product belonged to and added them to that group. We wanted to make use of aliases in migrated bugs so that we had a way to refer to the migrated bugs using their original bug number, we did this by prepending the string XIM to the bug number in our xsl stylesheet. We added the alias field to the import code. Ximian's bugzilla outputs all the long desc info as base64. I am not sure if this was their own hack or if this was default behavior in 2.10. We added code to decode it first if it's encoding was base64 Move.pl does not transfer attachments but the 2.10 xml.cgi includes attachment info. We added code to import attachments if present. This would be a desirable enhancement to move.pl. Bugs that were marked duplicate cannot be put in the duplicates table since there is no way of knowing if the duplicate bug has been moved as well, and if so what number it now has. To prevent sanitycheck from complaining, we change the resolution of these bugs from DUPLICATE to MOVED. This is likely only an issue for groups migrating products wholsale as we are doing. As for the everconfirmed, I simply check to see if the status is unconfirmed and if so leave the everconfirmed at 0, otherwise I set it to 1. Since no vote information is included in the move and since the number of votes needed to confirm a bug between the two bugzilla's may not be the same, this seemed the most logical.
Assignee | ||
Updated•19 years ago
|
Attachment #177022 -
Flags: review?(travis)
Updated•19 years ago
|
Assignee: nobody → ghendricks
Assignee | ||
Updated•19 years ago
|
Attachment #177022 -
Attachment is obsolete: true
Assignee | ||
Updated•19 years ago
|
Whiteboard: blocker will fix
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Updated•19 years ago
|
Attachment #177022 -
Flags: review?(travis)
Comment 10•19 years ago
|
||
fixed by bug 285614
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•