Description
Martin Renvoize (ashimema)
2018-10-02 09:22:13 UTC
With the introduction of the ability to search using 003 as part of the query for analytics, we should account for this in the cataloguing workflow. We should check for the presence of 'MarcOrgCode' being defined (at library or system level) and if it is being used we should copy the value of the 003 of the parent record into the constructed 773. This makes sense, but I think we need a depends on for the bug adding the 003 index? Created attachment 124426 [details] [review] Bug 21469: Add 003 into 773$w when required This patch looks at the MarcOrgCode preference and if present it will prepend the host 003 data in brackets to the 773$w link field in the child record. Created attachment 124427 [details] [review] Bug 21469: Add 003 into 773$w when required This patch looks at the MarcOrgCode preference and if present it will prepend the host 003 data in brackets to the 773$w link field in the child record. I'd love your help with writing a test plan for this Katrin.. I think it should work as expected, but I'm not even actually sure if we need to bind it on the presence of MARCOrgCodes being defined.. we might actually be OK just always prepending 003 if/when it's present in the host record. Created attachment 168272 [details] [review] Bug 21469: Add 003 into 773$w when required This patch looks at the MarcOrgCode preference and if present it will prepend the host 003 data in brackets to the 773$w link field in the child record. Is this to add the MARCOrgCode to 773 when using the "Add analytics" button in the cataloguing editor? Sorry, slightly confused right now again by our analytics :) Not related to this, but wondering from looking at the patch: Shouldn't the 11 here not be 111? if ( $field = $host->field('100') || $host->field('110') || $host->field('11') ) { Haha, that 11 instead of 111 may well have been you in bug 6831. I didn't change it here. This is around the 'UseControlNumber' and 'Enhanced workflow' stuff. It's all related to the work we were doing around the time in 2018 and 2021 to try and clarify and improve the 003 + 001 MARC linking stuff. I just couldn't wrap my mind around it first time, I will try again a little later. Thanks for the patch! Another 5 months on... I just found out about this bug thanks to ashimema on Mattermost!! It's great! I think this bug should refer to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34482 , " Improve MARC21 7xx linking fields in bibliographic records [Omnibus]." And the formatting could be corrected, c.f. the correctly formatted examples in the MARC21 format for the 773 field, https://www.loc.gov/marc/bibliographic/bd773.html So rather than prepending the data from the 003 in brackets, it should be in parentheses. And depending on the source code in the 003, there are differences, e.g.: OCLC records (yes, tons of libraries don't use OCLC, but as the largest source of bibliographic records in the world, there are a lot of OCLC records out there!): A child record such as this one: https://keys.bywatersolutions.com/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=36264 Generated from a parent record such as this one: https://keys.bywatersolutions.com/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=41131 Needs the alphabetic characters preceeding the OCLC number in from the 001 field stripped if they are present. More information on OCLC number formatting in 001 fields over time is here: https://help.oclc.org/Metadata_Services/WorldShare_Collection_Manager/Data_sync_collections/Prepare_your_data/30035_field_and_OCLC_control_numbers DLC records would need spacing respected (corrected?), c.f. the examples in the MARC21 format. I would like to be able to sign off on this bug when it's ready, but I'm not really seeing a test plan yet--are y'all still working on it, ashimema & Katrin? Tx! h2 |