[Bug 6113] New: enhancement to keep previous ids
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Bug #: 6113 Summary: enhancement to keep previous ids Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic record staging/import AssignedTo: gmcharlt@gmail.com ReportedBy: lculber@mdah.state.ms.us QAContact: koha-bugs@lists.koha-community.org CC: ian.walls@bywatersolutions.com Enhance bulkmarcimport.pl to keep ids of previous Information Library System when loading both bibliographic and authority records. Amend and improve the documentation about the the various options. The ids could be in tag without subfields (like '001'). The ids must to be only numeric. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Zeno Tajoli <tajoli@cilea.it> changed: What |Removed |Added ---------------------------------------------------------------------------- Change sponsored?|--- |Sponsored -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Change sponsored?|Sponsored |Seeking developer --- Comment #1 from Galen Charlton <gmcharlt@gmail.com> 2011-04-08 13:01:21 UTC --- Based on your mailing list post, I have changed the status of the bug to 'seeking developers'. Now, a question: Based on my understanding of what you put in the bug, what you're looking for are changes to bulkmarcimport.pl to do the following: [1] Look for a legacy record ID in a field specified by the user. [2] Make sure that that original ID is retained, possibility moving it to a different field specified by the user. [3] Improve the documentation of bulkmarcimport.pl. And all of this to serve the following purpose: to ensure that 76X-78X links will continue to work. Am I understanding that correctly? And would you mind attaching to this bug an example bib record where this applies? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #2 from lculber@mdah.state.ms.us 2011-04-08 17:41:01 UTC --- Created attachment 3845 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3845 sample of 16 records. previous id in 001 and 999 subfield c -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Hyperborea <koha@hyperborea.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |koha@hyperborea.com --- Comment #3 from Hyperborea <koha@hyperborea.com> 2011-04-12 10:08:04 UTC --- We are interested in developing this enhancement, so we changed bug status to "assigned". We will study a little what is needed, then we will add more details in next days. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW --- Comment #4 from Galen Charlton <gmcharlt@gmail.com> 2011-04-12 11:34:57 UTC --- (In reply to comment #3)
We are interested in developing this enhancement, so we changed bug status to "assigned". We will study a little what is needed, then we will add more details in next days.
While there is nothing stopping you, please note that I believe that the original poster is looking for proposals to perform the development. If you wish to provide a price quote, please email Linda. If you wish to just do the coding outright, you can assign the bug to yourself. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 MJ Ray (software.coop) <mjr@ttllp.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjr@ttllp.co.uk --- Comment #5 from MJ Ray (software.coop) <mjr@ttllp.co.uk> 2011-04-15 18:52:06 UTC --- (In reply to comment #0)
Enhance bulkmarcimport.pl to keep ids of previous Information Library System when loading both bibliographic and authority records.
Call me dense, but why not do this when converting the records produced by the previous ILS? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #6 from Galen Charlton <gmcharlt@gmail.com> 2011-04-15 19:02:45 UTC --- (In reply to comment #5)
(In reply to comment #0)
Enhance bulkmarcimport.pl to keep ids of previous Information Library System when loading both bibliographic and authority records.
Call me dense, but why not do this when converting the records produced by the previous ILS?
Well, preprocessing is certainly a valid option, but retaining the original LMS ID (when it is numeric, of course), is a minor improvement and simplifies the processing for Linda's particular use case. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> 2011-04-15 19:10:53 UTC --- I am not sure manipulating an internal database id that way is a good idea. And I am not sure this will always work. What if the old system's internal number is alphanumeric, has leading zeros in the number, is too long or something? What will happen when you delete or add a new record? I was told that relying on Control number in 001 and using that for linking is too slow compared to using an internal number. That said I have to say that it works for us and our libraries. What about adding a new column to the biblio table? This could be mapped to 001 or to any other field containing the old number in your data. And make it possible to construct a URL using that? Would this make things faster? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #8 from Galen Charlton <gmcharlt@gmail.com> 2011-04-15 19:14:16 UTC --- (In reply to comment #7)
What about adding a new column to the biblio table? This could be mapped to 001 or to any other field containing the old number in your data. And make it possible to construct a URL using that? Would this make things faster?
In the specific use case, an option to bulkmarcimport.pl to set the biblionumber explicitly is sufficient, but the idea of storing other standard identifiers would be useful, though possibly as a new table instead of just a column. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Zeno Tajoli <tajoli@cilea.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tajoli@cilea.it --- Comment #9 from Zeno Tajoli <tajoli@cilea.it> 2011-04-16 11:13:21 UTC --- (In reply to comment #7)
What if the old system's internal number is alphanumeric, has leading zeros in the number, is too long ... ?
well this enhancement is to use in migration, not during production. The idea is to create a perfect sync between old ILS ids and the values in: biblio.biblionumber, biblioitems.biblionumber, biblioitems.biblioitemnumber, items.biblionumber, items.biblioitemnumber and also the marc fields connenct with them (in marc21 standard KohaToMarc links 999$c and 999$d, for unimarc 001 and 090$a) so Q:What if the old system's internal number is alphanumeric ? A:This enhancement will not work. It works only with numbers. The sql defintion of biblio.biblionumber is: `biblionumber` int(11) NOT NULL auto_increment, Q:..has leading zeros in the number ? A: You need to delete leanding zeros before use bulkmarcimport.pl Q: .. is too long ? The max value in field biblio.biblionumber is 4294967295, if your numbers is bigger, bulkmarcimport.pl will no works. But we can plan to change biblio.biblionumber sql definition. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Change sponsored?|Seeking developer |Sponsored -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #10 from Galen Charlton <gmcharlt@gmail.com> 2011-04-19 17:13:45 UTC --- Details of proposed change - add four new parameters to bulkmarcimport.pl: • --reuse-legacy-rec-id - when specified, set the biblionumber (or authority iD) of a new imported record to the numeric ID present in the MARC record • --legacy-rec-id-tag - when specified, the tag containing the legacy bib or authority ID. If not specified, defaults to the biblionumber/authoritynumber tag set in the default MARC framework. • --legacy-rec-id-subf - like --legacy-rec-id-tag, but for the subfield • --overlay-on-rec-id - when specified, if an incoming record has the same bib ID as an exist Koha bib or authority, the Koha record will be replaced by the incoming record. This option is effectively only when --reuse-legacy-rec-id is on. If --reuse-legacy-rec-id is enabled but --overlay-on-rec-id is not, if an incoming record matches an existing Koha record, the record would instead be written to an exception file. If --reuse-legacy-rec-id is in effect but the ID found in the tag/subfield for the legacy record is not numeric, the record will be written to an exception file. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #11 from Galen Charlton <gmcharlt@gmail.com> 2011-05-27 03:15:14 UTC --- Work to date can be found at: http://git.esilibrary.com/?p=koha-equinox.git;a=shortlog;h=refs/heads/enh/bu... -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #12 from Galen Charlton <gmcharlt@gmail.com> 2011-05-27 03:16:02 UTC --- Description of change; determined that options could be simplified to: -reject-file FILE If specified, MARC records rejected during the course of processing are written to the file specified by this option. -recid-from-field TAG[:SUBFIELD] If specified, the specified tag/subfield is assumed to contain the record ID to assign to each loaded record. If a record with that ID already exists in the database, it will be replaced by the incoming record. If the incoming record lacks the ID field or the ID field doesn't contain an integer value, the record will be written the reject file. This option cannot be used at the same time as -match. The primary use case for -recid-from-field is for an initial load where it may be desirable to set the record ID during preprocessing. The secondary use case is for overlaying records on record ID (e.g., after authority record cleanup); the record ID lookups in that specific case can be faster than using the -match option. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #13 from Zeno Tajoli <tajoli@cilea.it> 2011-05-27 07:21:48 UTC --- I think that #12 is enough, but we need also to be more explicit on the help about the options --keepids=<FIELD> and -keepids -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #14 from Stefano Bargioni <bargioni@pusc.it> 2011-12-02 10:04:27 UTC --- Created attachment 6527 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6527 An utility to complement bulkmarcimport.pl Rather then improve bulkmarcimport.pl, sysno_keeper.pl works on biblio, biblioitems and items tables with a series of SQL commands, to reassign biblionumber and biblioitemnumber copying them from a control or data field (default 001). -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olli-antti.kivilahti@jns.fi Assignee|gmcharlt@gmail.com |olli-antti.kivilahti@jns.fi -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.4 |3.12 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #15 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 21698 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21698&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Created the test cases. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21698|0 |1 is obsolete| | --- Comment #16 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 21699 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21699&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Created the test cases. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21699|0 |1 is obsolete| | --- Comment #17 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 21700 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21700&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Forgot the extra warnings in C4::Biblio. Removed double warnings. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21700|0 |1 is obsolete| | --- Comment #18 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 21701 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21701&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Fixed warning messages. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21701|0 |1 is obsolete| | --- Comment #19 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 21702 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21702&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Modified the C4::Biblio::_koha_add_biblioitem() && _koha_add_biblio() to support INSERTing biblionumbers and biblioitemnumbers to the DB. Also validating that id's are positive integers and well below the critical Perl LONG_MAX limit so we don't get buffer overflow. Duplicate id INSERTion will fail, but in normal use scenarios this is not an issue, if "Koha to MARC mapping" has biblionumber and biblioitemnumber mapped under field 999. MySQL takes care of the primary key sequence refreshing. Updated the bulkmarcimport.pl -script to copy the desired legacy id MARC field to the field designated in "Koha to MARC mapping" -> biblionumber && biblioitemnumber. This is handy if you have the legacy id in just 001 and need to populate 999c and 999d to push them to DB. No need to make an extra modification run to source bibliographic records just to facilitate Koha migration better. Documented the new functionality in bulkmarcimport.pl -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21702|0 |1 is obsolete| | --- Comment #20 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 21703 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21703&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Modified the C4::Biblio::_koha_add_biblioitem() && _koha_add_biblio() to support INSERTing biblionumbers and biblioitemnumbers to the Koha DB. Created validators to make sure the primary keys are positive integers and well below the Perl's LONG_MAX threshold to keep Koha from getting crazy. Duplicate id's are the users responsibility and in normal use conditions they are non-existing, unless the "Koha to MARC mapping" to biblionumber is a user-modifiable MARC field, which is TROUBLE! MySQL takes care of the primary key sequence refreshing. Updated the bulkmarcimport.pl -script to copy the desired legacy id MARC field to the biblionumber- and biblioitemnumber-fields designated in "Koha to MARC mapping", eg. copy field 001 to 999c and 999d. This is handy if you have the legacy id in just 001 and need to populate 999c and 999d to push them to DB. No need to make an extension to the existing migration scripts. Documented the new functionality in bulkmarcimport.pl Created test cases for C4::Biblio.pm modifications. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Hours Worked| |12.00 Patch complexity|--- |Medium patch -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff --- Comment #22 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Sponsored-by: Joensuu Regional Library -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 I'm just a bot <gitbot@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gitbot@bugs.koha-community. | |org When did the bot| |2013-10-02 last check this| | --- Comment #23 from I'm just a bot <gitbot@bugs.koha-community.org> --- Patch applied cleanly, go forth and signoff -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion CC| |kyle@bywatersolutions.com --- Comment #24 from Kyle M Hall <kyle@bywatersolutions.com> --- Would it be possibly better to solve this using bug 8015 as a basis? It's a more extensible/flexible system and we could easily modify bulkmarcimport.pl to allow the use of modification templates. I know it means tossing this existing work, but I'd say it's usually better to have less code than more code. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #25 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> ---
Would it be possibly better to solve this using bug 8015 as a basis? It's a more >extensible/flexible system and we could easily modify bulkmarcimport.pl to allow >the use of modification templates. I know it means tossing this existing work, >but I'd say it's usually better to have less code than more code.
I think bug 8015 is a great basis for this, but I needed this functionality for our data migration and subsequently this bug was just a target of opportunity. Hopefully this helps someone else as well. It's fine by me that someone else will solve this problem with more style and potentially discard all the work I have made. Unfortunately this is way out of our scope, so that someone else wont be me. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21703|0 |1 is obsolete| | --- Comment #26 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 24073 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24073&action=edit Bug 6113 [ENH] - enhancement to keep previous ids Modified the C4::Biblio::_koha_add_biblioitem() && _koha_add_biblio() to support INSERTing biblionumbers and biblioitemnumbers to the Koha DB. Created validators to make sure the primary keys are positive integers and well below the Perl's LONG_MAX threshold to keep Koha from getting crazy. Duplicate id's are the users responsibility and in normal use conditions they are non-existing, unless the "Koha to MARC mapping" to biblionumber is a user-modifiable MARC field, which is TROUBLE! MySQL takes care of the primary key sequence refreshing. Updated the bulkmarcimport.pl -script to copy the desired legacy id MARC field to the biblionumber- and biblioitemnumber-fields designated in "Koha to MARC mapping", eg. copy field 001 to 999c and 999d. This is handy if you have the legacy id in just 001 and need to populate 999c and 999d to push them to DB. No need to make an extension to the existing migration scripts. Documented the new functionality in bulkmarcimport.pl Created test cases for C4::Biblio.pm modifications. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Patch doesn't apply --- Comment #27 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- This patch just created an issue for us in conjunction with Bug 12624. It was very useful in our initial migration but after that it will be worthless. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 --- Comment #28 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- BTW the issue was existing biblios getting overwritten by new records from staging tables. So if C4::Biblio::_koha_add_biblio() returns an error, the rest of the instructions are carried out normally, eg. ModBiblio, which overwrites the existing marc record even if the "adding new record to a reserved biblionumber" just failed. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtompset@hotmail.com --- Comment #29 from M. Tompsett <mtompset@hotmail.com> --- (In reply to Olli-Antti Kivilahti from comment #27)
This patch just created an issue for us in conjunction with Bug 12624.
It was very useful in our initial migration but after that it will be worthless.
So, should this be left as "Patch doesn't apply" or perhaps change it to "Resolved - Won't Fix"? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org