---- Reported by firstname.lastname@example.org 2010-05-17 13:42:48 ----
The scripts contains a lot of leaks, they must be enhanced.
--- Bug imported by email@example.com 2010-05-21 01:28 UTC ---
This bug was previously known as _bug_ 4518 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4518
Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Created attachment 4393 [details] [review]
(bug #4518) enhance 2.2 to 3.0 scripts
Signed-off-by: Chris Cormack <firstname.lastname@example.org>
mmm... frankly, do we have to care with this ? is there anyone/ppl needing to move from 2.2 ? I hope no !
I'll ask on koha mailing list immediatly.
Unfortunately there are hundreds of libraries around the world still running 2.2.x versions.
I know of many in malaysia and the philipines. Plus all the windows users.
It is unclear what exactly these enhancements are supposed to do, making it impossible to test (even if I had a 2.2 install to upgrade). Could I get some more background on what this patch is attempting to fix?
Those patches are supposed to deal with some specific cases, that either should not happend in a 2.2 DB, but sometimes happend, or cases that are rarely relevant, but we should deal with them.
I still have this patch on my todo list, will take care of it later (not on top of my list though)
Anyway, for most upgrades, this patch should be useless (but for some, the upgrade would fail or let the DB in an unconsistent state)
Two small QA remarks.
This pertains to UNIMARC only. Is not clear from name of script or initial comments. Compare with warning in misc/migration_tools/upgradeitems.pl.
The way the code uses $rqitemnumber is somewhat questionable. Apparently, you want to check the existence of itemnumber from 995 in items table. In the for loop at the end only the last item number is passed to ModItemFromMarc. I assume that there should always only be one subfield 9. Code will work therefore, but could be improved.
I set the status to Passed QA and let Paul decide if he wants to push or change status to Failed QA and work first on it. It should not stay on hold in the Signed Off queue.
Patch pushed, Chris_n, it's worth pushing it on 3.6. Once it's done, please close the bug directly, as it will be very hard to find someone in 2.2 that would test it.
If there is a problem appearing, they'll open another bug or reopen this one
This was included in the 3.6 branch prior to 3.6.4.