Created attachment 105608 [details]
After you make a search and the search result appears. Click on any title and you get an error message of "The record you requested does not exist ()".
Upon close inspection, I noticed that when you mouseover a title on the search result list, the biblionumber for that item is missing from the link URL. For example:
Once you entered a biblionumber, the normal catalogue record is showing.
So looks like biblionumber has dropped out for every catalogue record!
I'm running Koha 19.11.06.000 and have never made any setting change.
Hi, I have tested in 19.11.06 and the links work ok for me from catalog and cataloguing search. Usually the error you see appears when your index is not up to date and you have records in the result list that have since been removed from Koha. Please try a full reindex.
I am lowering the severity for now.
After upgraded to 20.05 and fully reindex, the problem still exist.
However I just noticed that in the staff client, on the search result list, if you click on the image column (whether there is a cover image or not), it will take you to the normal display (full catalogue record).
Whereas, if you click on the title hyperlink, the "biblionumber" is missing and thus cannot get to the normal (full record display).
In the OPAC, click on the cover image will take you to the full catalogue record. However, when there is no cover image ("No cover image" hidden), then you cannot get into the full catalogue record. You get an error message (see screenshot attached).
Does this have anything to do with Bug # 24740 (implemented recently)?
Created attachment 105611 [details]
OPAC full catalogue record access error
Which MARC format are you using?
Have you chanced the XSLT files in any way?
I believe this could also happen if your biblionumber is not stored in the expected MARC field. For MARC21 this would be 999.
We are using Marc21 and the default XSLT is used (admin preference never changed).
We have always used 999 $c and $d for biblionumber (even though, we also copy the exact same number to 001).
See screenshot attached.
Created attachment 105615 [details]
Sorry, not sure what's going on then. I can't replicate the bug on a fresh 19.11 installation.
I suspect this problem only occurred after we upgraded to 19.11.06 as it was working fine last week.
What do you have in OPACXSLTResultsDisplay? Did you modify the default XSLT?
Also, try to restart memcached, then koha-common.
We have made no change to any of our setting. Our IT person has setup an auto upgrade of Koha when available and we got 19.11.06 recently. To attempt to fix this problem, we have upgraded to 20.05 since without luck.
It seems that you have to click on the cover image instead of title to open the full catalogue (normal display). This causes a major problem in our OPAC as not all items have cover image.
I'm suspecting this behaviour may have something to do with Bug # 24740.
I don't think it's related with bug 24740.
Please confirm the value in the syspref and that you correctly restart the different services.
The problem you have is that the variable "biblionumber" is not correctly picked for the XSLT processing.
I also see different uncommon things in your catalogue:
- you have itemtypes with '*', like '*_LB', is that correct? Did you create it recently?
The issue was due to Bug 24458.
Iming's bibliographic frameworks are quite old I think, so they didn't have the OPAC and Intranet checkboxes ticked for the 999$c in the Default framework.
While a fresh database will have the latest MARC bibliographic framework, upgraded databases never get updated MARC bibliographic framework data.
This is an issue I've been pondering for years. Personally, I'd love to see the "Default Framework" be managed by Koha rather than by end users, so that we could constantly update it with the latest and greatest configuration.
> This is an issue I've been pondering for years. Personally, I'd love to see
> the "Default Framework" be managed by Koha rather than by end users, so that
> we could constantly update it with the latest and greatest configuration.
I am not sure about this, we'd need to allow local changes. For example we have several custom fields agreed on for data exchange in Germany and in between libraries in certain areas.
(In reply to Katrin Fischer from comment #15)
> > This is an issue I've been pondering for years. Personally, I'd love to see
> > the "Default Framework" be managed by Koha rather than by end users, so that
> > we could constantly update it with the latest and greatest configuration.
> I am not sure about this, we'd need to allow local changes. For example we
> have several custom fields agreed on for data exchange in Germany and in
> between libraries in certain areas.
Hmm that's a good point.
Maybe we should have a "Reference" MARC Bibliographic Framework that is not the "Default", but which gets updated during upgrades.
Maybe we could have a "diff tool" for showing the differences between "Reference" and any other framework, and have a user-friendly method for updating other frameworks from the "Reference" framework.
The onus would still be on Koha users to update their frameworks, but at least they'd have the ability to do it in a practical (and authoritative) way.
*** Bug 25826 has been marked as a duplicate of this bug. ***
I think we should make sure that the biblionumber cannot be hidden in the frameworks or at least output a warning on the system information tab if the field linked to biblionumber is set to hidden in OPAC.
(In reply to Katrin Fischer from comment #18)
> I think we should make sure that the biblionumber cannot be hidden in the
> frameworks or at least output a warning on the system information tab if the
> field linked to biblionumber is set to hidden in OPAC.
*** This bug has been marked as a duplicate of bug 19261 ***
Ok I just reproduced this in master on koha-testing-docker after hiding 999$c in Default and Books* frameworks, and then doing this staff interface search:
local-number:29 or local-number:30
It created search results with the following links:
As you can see, the biblionumber is missing.