An "additional" item appears in the staff interface if item = biblionumber. This effect is not observed in OPAC.
Can you give some more information or maybe a screenshot? Do you have EasyAnalytics activated?
I cannot recreate this situation. I have a lot of records where the biblionumber is the same as the itemnumber and there is no extra item. Can you provide a test plan?
Created attachment 160680 [details] staff
Created attachment 160681 [details] MARC preview
OPAC https://koha.lib.tpu.ru/cgi-bin/koha/opac-detail.pl?biblionumber=669655
Created attachment 160682 [details] OPAC
I looked at the screenshots and noticed that the item that appears in staff but not in the OPAC is withdrawn. Is it possible OPACHiddenItems hides withdrawn items from the OPAC? In the staff screenshot, the biblionumber seems to be 151173 and the itemnumber is 669653.
Created attachment 160731 [details] item number 669653 Item is withdrawn. Item number - 669653. biblionumber - 151173.
In the second screenshot, the biblionumber is 669655. 461$9 - link to biblionumber 669653. Perhaps it does not work correctly. Why itemnumber 669653 from biblionumber 151173 "appear" in biblionumber 669655?
Are you using EasyAnalytics?
I don't know the correct UNIMARC field, but if 461 is the field for linking analytics and $9 is a valid biblionumber... it all behaves like it should. Easyanalytics is used to show items from one record on another.
EasyAnalyticalRecords - Don’t show (Default) UNIMARC 461 Set 464 Piece-analytic
My guess is for this to be a side effect of EasyAnalytics - maybe something where the pref is not checked properly? If you remove the $9, the item goes away? What is the meaning of $9 in your 461?
How do I check EasyAnalytics? If delete $9, the item "disappears". $9 is created automatically when using /cgi-bin/koha/cataloguing/plugin_launcher.pl?plugin_name=unimarc_field_4XX.pl
If you could confirm that EasyAnalytics system preference is turned off than I'd say it's a bug on the check for the pref. But also: Would the item showing up make sense otherwise? The idea is that you can show the same item on multiple records with Analytics, so patrons can see if it's checked out on the host record and on the analytical (articles, etc.) records. I don't know UNIMARC well enough to answer that.
I confirm this bug, and that it is a bug. This is an UNIMARC-only bug. Even if EasyAnalytics isn't enabled, Koha will get related items from 773$9 (MARC21) or 461$9 for UNIMARC. I suppose that it make sense to always show related items to the librarians... But for UNIMARC, there is a big issue, 461$9 isn't at all supposed to contain the itemnumber of an item. It contains the biblionumber of a related biblio record. So the biblionumber is used to retrieve an item. You can image the confusion, and the unpredictability. My understanding is that analyticals aren't implemented at all for UNIMARC. So we should just stop trying to mimic something that has no purpose for UNIMARC installations.
Created attachment 178642 [details] [review] Bug 35545: Unexpected items in PRO (UNIMARC-only) In PRO, for UNIMARC installation, analytical related items are retrieved based on 461$9 content. But it can't work (like with MARC21 773$9 field) because 461$9 contains the biblionumber of a related biblio record. This must be completly disabled for UNIMARC.
See Bug 37964 related. We have several UNIMARC Koha that use this feature with 461$9. Looks like 461$0 contains biblionumber. The searchengine configuration must be adapted for this usage. But I think value builder unimarc_field_4XX.pl should not be used with EasyAnalyticalRecords system preference. As long as turning off EasyAnalyticalRecords works, I'd say we should not remove this feature for UNIMARC. I set to discussion.
Thanks Fridolin. I wasn't aware analytical feature was working with UNIMARC. For me Bug 37964 is the solution. But it means that linking biblio records together with unimarc_field_4xx plugin, and using analytical feature is not possible. It's unfortunate. But I suppose this issue could be fixed elsewhere and differently. This bug could be closed. No?
I'd say close ;)
After updating to 24.11.03, the error "disappeared". Thanks!