Summary: | Enhance 2.2 to 3.0 scripts | ||
---|---|---|---|
Product: | Koha | Reporter: | Nahuel Angelinetti <nahuel.angelinetti> |
Component: | Installation and upgrade (command-line installer) | Assignee: | Paul Poulain <paul.poulain> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | normal | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, koha.sekjal, m.de.rooy, paul.poulain |
Version: | 3.6 | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: | (bug #4518) enhance 2.2 to 3.0 scripts |
Description
Chris Cormack
2010-05-21 01:28:07 UTC
Created attachment 4393 [details] [review] (bug #4518) enhance 2.2 to 3.0 scripts Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> QA comment: 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? Ian, 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. move_marc_to_authheader.pl This pertains to UNIMARC only. Is not clear from name of script or initial comments. Compare with warning in misc/migration_tools/upgradeitems.pl. 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. |