http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10462
Galen Charlton <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA CC| |[email protected] --- Comment #11 from Galen Charlton <[email protected]> --- This patch changes what gets returned as the LCCN. The acronym "LCCN" is ambiguous, unfortunately, as it can refer to LC Control Number or LC Call Number. The current behavior of the Z39.50 search is to return the former (i.e., the control number or LC-assigned identification number). Here is a diff (before and after applying the patch) of the output of a little test script I wrote that searches LC's Z39.50 server for ISBN 9780415964845. 'total_pages' => 1, 'breeding_loop' => [ { - 'lccn' => ' 2008005439', - 'breedingid' => '91', - 'date' => '2008', - 'author' => undef, + 'lccn' => 'PR6068.O93', + 'date' => '2008.', + 'breedingid' => '92', + 'author' => '', 'biblionumber' => undef, 'edition' => '2nd ed.', 'server' => 'LIBRARY OF CONGRESS', I'm marking this as failed QA for the change in visible behavior, but this issue speaks to a broader concern I have with this patch: why replace the call to TransformMarcToKoha, which uses the installed default bibliographic framework to extract strings from the MARC record, with hardcoding the tags and subfields for each MARC flavor? -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
