Closed Bug 85841 Opened 23 years ago Closed 19 years ago

move fails to correctly set everconfirmed


(Bugzilla :: Bug Import/Export & Moving, defect, P1)




Bugzilla 2.22


(Reporter: timeless, Assigned: gregaryh)



(Whiteboard: blocker will fix)


(1 obsolete file) 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
Target Milestone: --- → Bugzilla 2.16
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.
Priority: -- → P1
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: Bugzilla 2.13 → 2.10
correcting version field lost in product move
Version: 2.10 → 2.13
*** Bug 109819 has been marked as a duplicate of this bug. ***
no patch, not a blocker, 2.16 is now in freeze mode

-> 2.18
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
*** Bug 128424 has been marked as a duplicate of this bug. ***
Component: Bugzilla-General → Bug Import/Export & Moving
Assignee: endico → nobody
These bugs appear to be abandoned.  Retargeting to 2.20
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
I think it would be nice to get this fixed for 2.20.
I have a patch for 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.
Attached patch patch (obsolete) — Splinter Review
This patch addresses a number of issues with, but first let me
explain the background of the changes we have made.

We have been migrating large numbers of bugs from to (on the order of thousands) so we needed to automate the
process a little. 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

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 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

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.
Attachment #177022 - Flags: review?(travis)
Assignee: nobody → ghendricks
Depends on: 285614
Attachment #177022 - Attachment is obsolete: true
Whiteboard: blocker will fix
Attachment #177022 - Flags: review?(travis)
fixed by bug 285614
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.