Summary: | ShowComponentRecords doesn't display components if UseControlNumber is turned on | ||
---|---|---|---|
Product: | Koha | Reporter: | Caroline Cyr La Rose <caroline.cyr-la-rose> |
Component: | Cataloging | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | esther.melander, lari.taskula, lucas, m.de.rooy, magnus |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30327 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 11175 | ||
Bug Blocks: |
Description
Caroline Cyr La Rose
2022-09-22 19:54:06 UTC
Hi Caroline, same issue with Elasticsearch/Zebra? (In reply to Katrin Fischer from comment #1) > Hi Caroline, same issue with Elasticsearch/Zebra? I did this with ES on my local installation and with Zebra on a BW sandbox. Hi Caroline, do you still happen to know were you were testing? If it was an updated installation, the cnr index might have been missing as it's not added on update for Elasticsearch. So the question then is perhaps if this was never implemented with UseControlNumber, or if it was implemented and some bug snuck in and made it not work any more? In t/db_dependent/Koha/Biblio.t there is a set of subtests labeled "get_components_query", which seems to be testing with UseControlNumber both off and on. And the tests pass. The original bug 11175 has this patch: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=126882 "Taking the code in bug 15851 as inspiration this patch also adds proper handling for UseControlNumber vs EasyAnalytics style 773 linking and ensures we only return analytic component parts and no other records containing 773's." Sounds to me like it should work. I'm changing this from "enh" to "normal bug". It should work if a library is using control-numbers for linking, I am pretty sure I tested this. Needs some more testing I think to see where the problem is. @Caroline: did you check on the existence of the cnr index in your installation? ShowComponentRecords appeared to be working in 23.05 but does not seem to be working in 23.11. To replicate: 1. Ensure the 773 tag is available in the framework. 2. Ensure the system preference EasyAnalyticalRecords is set to don't show 3. Ensure UseControlNumber is set to use. 4. Configure ShowComponentRecords for staff interface 4. Add a serial record, ensure the Leader space 7 is a serial. 5. From the new serial record, Edit - Add new child record. 6. Add the child record and ensure the 773 $w has the 001 control number from the host/parent record. Also ensure the Leader space 7 is a serial component part. 7. Add another child record. The child record should have an "In: Serial Title" link in the bibliographic record detail view. Click on this link to return to the parent record. See that the Component tab is missing from the holdings table of the parent record. Just confirmed this on 23.05.12. Turning off UseControlNumber makes the "Components" tab show in staff detail view. It works in 24.05 and Elasticsearch. First off, when UseControlNumber is enabled and host record has both 001 and 003 filled in, the component records are loaded into the host record by the following search query: (((rcn:"Host001" AND cni:"Host003") OR rcn:"Host003 Host001") AND (bib-level:a OR bib-level:b)) For example: (((rcn:"011193623" AND cni:"FI-MELINDA") OR rcn:"FI-MELINDA 011193623") AND (bib-level:a OR bib-level:b)) If you are having problems displaying the component records with UseControlNumber and ShowComponentRecords on, try narrowing down the problem by first searching: ((rcn:"Host001" AND cni:"Host003") OR rcn:"Host003 Host001") (fill in Host001 and Host003 values) If you get no results, then it could be that the child 773$w != host 001 or child 003 != host 003. If they are correct and you still get no results with the narrowed down query, check your Elastic mappings for rcn and cni. On the other hand if you do get the component records as results, then your child's leader character position 7 is not really "a" or "b". Leader's pop-up editor can be misleading when viewing the values. To reproduce: 1. Click "New child record" from the host 2. Fill in other mandatory fields but do not touch the leader 3. Save the child record 4. Edit the child record 5. Edit the leader 6. Observe 7- Bibliographic level shown as "a" 7. Close leader (do not save) editor pop-up 8. Count leader characters manually until position 7 (starting from 0) 9. Observe it being empty! This can be very misleading and is caused by "a" being the default select option. So you always have to edit the leader manually for it to work, or use a different MARC framework with default values for component records. Enhancement: Could "New child record" button automatically populate char position 7 of the child to avoid this problem? In fact I assumed this was already the case but it seems it is not. Checklist: - UseControlNumber ON - ShowComponentRecords ON - Make sure rcn (record-control-number => 773w) and cni (control-number-identifier 003) are mapped in Elastic mappings (bibliographic records tab) - Host 001 and child 773$w are equal - Host 003 and child 003 are equal - Child's leader character position 7 is truly "a" or "b" (count character positions manually - do not trust the editor's drop-down value). Keeping these things in mind it should work in 24.05. |