http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13163
Magnus Enger <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #32964|0 |1 is obsolete| | --- Comment #3 from Magnus Enger <[email protected]> --- Created attachment 32967 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32967&action=edit Bug 13163: NORMARC DOM config missing <id> entry This patch fixes the biblio-koha-indexdefs.xml for NORMARC, so it includes the <id> element. Because of how our DOM files work, the resulting biblio-zebra-indexdefs.xsl for NORMARC picked the whole MARC record as ID, so every time the record was edited, the id wouldn't match and a new record was created. To test: - Have a MARCXML record - run: $ xsltproc etc/zebradb/marc_defs/normarc/biblios/biblio-zebra-indexdefs.xsl the_record | less => FAIL: verify the z:id property on the <z:record> line contains all subfields concatenated - Apply the patch - re-run the xsltproc line => SUCCESS: z:id contains the 999$c number - Sign off :-D Regards Signed-off-by: Frederic Demians <[email protected]> Known bug with DOM: Without <z:id> indexing biblionumber Zebra hasn't it record unique ID, and so fails to identify existing records. Works as described. 999$c is linked to biblionumber in default Normarc framework. Signed-off-by: Magnus Enger <[email protected]> I have applied the patch to my production server, and at least one customer has confirmed that it fixes the problem with multiple copies of records in search results. -- 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/
