While hunting through my live system Koha error logs I found: auth_finder.pl: Odd number of elements in anonymous hash at /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 1037. So, I read the code and wondered what if a tag was missing in the giant if statement? http://www.loc.gov/marc/authority/ad1xx3xx.html lists a 162, but there is no 162, nor is there an else on the giant if statement. Test? I don't know, but the patch that follows should fix it.
Created attachment 25478 [details] [review] Bug 11797 - auth_finder.pl: Odd number of elements in anonymous hash Added missing 162 MARC authorities tag and missing else case. If the records are not in a given order the first substring of the previous tag could be not 'a', but only 'a' exists for 162, so the hash would have "hemain => " which triggers the error. That's my theory anyways.
Created attachment 25882 [details] [review] Bug 11797 - Odd number of elements in hash This was discovered when someone triggered an authority search on an authority record that was missing what is assumed the default subfield for a given field. It, however, also can be triggered in an OPAC authority search by looking at the record that lacks the default subfield for a given field. TEST PLAN --------- 1) Create an authority record with 180$x and NOT 180$v. See C4::AuthoritiesMarc::BuildSummary in the 1.. foreach loop for known tags and default values. The default subfields are the first letter of the $subfields_to_report string. 2) Trigger the bug: Method 1: /cgi-bin/koha/opac-authoritiesdetail.pl?authid=# Where # is the authority id of your tweaked record. The error occurs in Normal view. Method 2: Home -> Cataloging -> + New record -> Click the 'Tag Editor' on 100$a ... 3) Notice there is an error log entry. 4) Apply the patch 5) Attempt to trigger the bug again 6) Error log entry is not generated.
Created attachment 25884 [details] [review] Bug 11797 - Odd number of elements in hash This was discovered when someone triggered an authority search on an authority record that was missing what is assumed the default subfield for a given field. It, however, also can be triggered in an OPAC authority search by looking at the record that lacks the default subfield for a given field. TEST PLAN --------- 1) Create an authority record with 180$x and NOT 180$v. See C4::AuthoritiesMarc::BuildSummary in the 1.. foreach loop for known tags and default values. The default subfields are the first letter of the $subfields_to_report string. 2) Trigger the bug: Method 1: /cgi-bin/koha/opac-authoritiesdetail.pl?authid=# Where # is the authority id of your tweaked record. The error occurs in Normal view. Method 2: Home -> Cataloging -> + New record -> Click the 'Tag Editor' on 100$a Editing of $a to $b and back may be required. 3) Notice there is an error log entry. 4) Apply the patch 5) Attempt to trigger the bug again 6) That specific error log entry is not generated.
Created attachment 27077 [details] [review] Bug 11797 - Odd number of elements in hash This was discovered when someone triggered an authority search on an authority record that was missing what is assumed the default subfield for a given field. It, however, also can be triggered in an OPAC authority search by looking at the record that lacks the default subfield for a given field. TEST PLAN --------- 1) Create an authority record with 180$x and NOT 180$v. See C4::AuthoritiesMarc::BuildSummary in the 1.. foreach loop for known tags and default values. The default subfields are the first letter of the $subfields_to_report string. 2) Trigger the bug: Method 1: /cgi-bin/koha/opac-authoritiesdetail.pl?authid=# Where # is the authority id of your tweaked record. The error occurs in Normal view. Method 2: Home -> Cataloging -> + New record -> Click the 'Tag Editor' on 100$a Editing of $a to $b and back may be required. 3) Notice there is an error log entry. 4) Apply the patch 5) Attempt to trigger the bug again 6) That specific error log entry is not generated. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Could generate the warning with a missing 151$a with both methods. No warning anymore after applying this patch.
Created attachment 27120 [details] [review] Bug 11797 - Odd number of elements in hash - UNIMARC I got the same warning for my UNIMARC DB. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Double-checking: was the MARC21 variant of this patch marked obsolete by mistake?
Created attachment 27133 [details] [review] Bug 11797 - Odd number of elements in hash This was discovered when someone triggered an authority search on an authority record that was missing what is assumed the default subfield for a given field. It, however, also can be triggered in an OPAC authority search by looking at the record that lacks the default subfield for a given field. TEST PLAN --------- 1) Create an authority record with 180$x and NOT 180$v. See C4::AuthoritiesMarc::BuildSummary in the 1.. foreach loop for known tags and default values. The default subfields are the first letter of the $subfields_to_report string. 2) Trigger the bug: Method 1: /cgi-bin/koha/opac-authoritiesdetail.pl?authid=# Where # is the authority id of your tweaked record. The error occurs in Normal view. Method 2: Home -> Cataloging -> + New record -> Click the 'Tag Editor' on 100$a Editing of $a to $b and back may be required. 3) Notice there is an error log entry. 4) Apply the patch 5) Attempt to trigger the bug again 6) That specific error log entry is not generated. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Could generate the warning with a missing 151$a with both methods. No warning anymore after applying this patch. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 27134 [details] [review] Bug 11797 - Odd number of elements in hash - UNIMARC I got the same warning for my UNIMARC DB. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Can we reset the status of this report?
I agree it should be changed. I don't think Jonathan's patch has been signed off, hence the 'Needs Signoff' status.
Pushed to master, along with a follow-up to normalize the two approaches taken to remove the warning and a patch that adds unit tests and regression tests. Thanks, Mark and Jonathan! Jonathan: I would be interested in seeing an example of a valid UNIMARC authority that triggers the bug.
Pushed to 3.14.x, will be in 3.14.10