Created attachment 169943 [details] Errors from Dev tools After upgrade to 24.04, the Items list don't show because it's stucked on Processing... This happens in "Normal View" from Staff Interface
We are seeing this too after our dev was updated to 24.05. Getting a 500:Internal Server Error on all bib records with the Processing box just stuck. Screenshot of a bib record attached.
Created attachment 169965 [details] Holdings 500 error
Hi, please check if you are missing item subfields in your frameworks. This sounds like it could be Bug 37375 - Holdings table not loading if MARC framework is missing certain 952 subfields
See also Bug 37416 - I started recording some of the reported errors, and looking for ways to identify data issues. Maybe this bug is a duplicate of 37416?
(In reply to Katrin Fischer from comment #3) > Hi, please check if you are missing item subfields in your frameworks. This > sounds like it could be > > Bug 37375 - Holdings table not loading if MARC framework is missing certain > 952 subfields That's probably right. I checked the "MARC bibliographic framework test" and there are several errors. It's strange the upgrade change these settings... I'll correct it and give the feedback.
The update didn't change the frameworks, but the new display for items is a bit more picky if definitions are missing.
Something had to change. I'm 100% sure everything was OK. I've already managed to change some, but others are complicated. Probably only on Monday I will continue.
Created attachment 170006 [details] Framework test NOT OK
(In reply to Katrin Fischer from comment #6) > The update didn't change the frameworks, but the new display for items is a > bit more picky if definitions are missing. (In reply to José Anjos from comment #7) > Something had to change. > I'm 100% sure everything was OK. > I've already managed to change some, but others are complicated. > Probably only on Monday I will continue. Yes, I was just trying to say that the update didn't change the frameworks, but errors in the frameworks such as missing subfields for 952 can break the display now because we re-did the item display in staff. We might be able to improve that, but for now fixing the 952 or fixing your data might help things. Please let us know what worked for you.
All of the subfields are present in our frameworks, but not every item has something IN those frameworks. Do all of those subfields ($8, $a, $b, $c, and $y) now have to have information in them for any items to appear? We only have $y set as required.
(In reply to Angela Berrett from comment #10) > All of the subfields are present in our frameworks, but not every item has > something IN those frameworks. Do all of those subfields ($8, $a, $b, $c, > and $y) now have to have information in them for any items to appear? We > only have $y set as required. What should be mandatory is a, b and y. Usually a and b will be automatically set to yoru logged in library, but worth checking if they are set correctly for your items.
We have over 230,000 items with no branch, collection code, and/or shelf location. Is there a reference to a bug/development where the changes to the Holdings table were discussed and these fields were decided to be required? Just curious where this came from since we weren't prepared for it. Thanks!
(In reply to Angela Berrett from comment #12) > We have over 230,000 items with no branch, collection code, and/or shelf > location. Is there a reference to a bug/development where the changes to > the Holdings table were discussed and these fields were decided to be > required? Just curious where this came from since we weren't prepared for > it. Thanks! The changes to the holdings table were made in bug 33568 (it's a long bug to read through, and I didn't work on it - so I'm not sure whether it was intended or not, or whether these subfields have been implicitly required for some time). The main purpose of the bug was to improve loading performance when then are many items for a record - something that has been an issue for some time. I created bug 37416 to try and share some ways to identify any potential issues with your data, and how to fix them up.
(In reply to Angela Berrett from comment #12) > We have over 230,000 items with no branch, collection code, and/or shelf > location. Is there a reference to a bug/development where the changes to > the Holdings table were discussed and these fields were decided to be > required? Just curious where this came from since we weren't prepared for > it. Thanks! Hi Angela, collection and location (CCODE and LOC) are not mandatory, you don't need to fix these. The fields only need to exist in the frameowrk. But the holdingbranch and homebranch (a and b in MARC21) definitely need to be set for Koha to work correctly, this is going to be considered a data issue that needs to be fixed on your end. It will cause other issues too, unrelated to the items table.
Okay - I spent yesterday pulling lists of everything and will start the cleanup today. Thank you for helping me figure all of this out!
(In reply to Angela Berrett from comment #15) > Okay - I spent yesterday pulling lists of everything and will start the > cleanup today. Thank you for helping me figure all of this out! For a first test, could you update a record manually and confirm that adding the a and b makes the table load OK?
(In reply to Katrin Fischer from comment #16) > (In reply to Angela Berrett from comment #15) > > Okay - I spent yesterday pulling lists of everything and will start the > > cleanup today. Thank you for helping me figure all of this out! > > For a first test, could you update a record manually and confirm that adding > the a and b makes the table load OK? Actually - I just tried to pull a list of everything in our dev environment (which is at 24.05, our prod isn't updated yet) and there is not a single item that does not have 952$a, $b, and $y in it. I've opened a ticket with ByWater to see if they can assist me here.
(In reply to Angela Berrett from comment #17) > (In reply to Katrin Fischer from comment #16) > > (In reply to Angela Berrett from comment #15) > > > Okay - I spent yesterday pulling lists of everything and will start the > > > cleanup today. Thank you for helping me figure all of this out! > > > > For a first test, could you update a record manually and confirm that adding > > the a and b makes the table load OK? > > Actually - I just tried to pull a list of everything in our dev environment > (which is at 24.05, our prod isn't updated yet) and there is not a single > item that does not have 952$a, $b, and $y in it. I've opened a ticket with > ByWater to see if they can assist me here. Thanks Angela - not good news in a way, but I hope that ByWater can pull the error behind this from the logs so we can fix it.
I'm using UNIMARC. According this table: https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx) UNIMARC MARC 21 995$b 952$a branchcode items.homebranch owning library 995$c 952$b branchcode items.holdingbranch holding library (usu. the same as 952$a ) 995$k 952$o Koha full call number items.itemcallnumber 995$f 952$p * barcode items.barcode max 20 characters 995$r 952$y * Koha item type items.itype coded value, required field for circulation The field 995$b (MARC21 952$a ) branchcode, items.homebranch, owning library, gives an error in MARC bibliographic framework test. I had to change it to 995$a again. Even so, I still have 2 errors: itemtype NOT mapped the biblioitems.itemtype field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have "Authorized value" set to "itemtype" and biblio and biblionumber The biblio.biblionumber and biblioitems.biblioitemnumber fields be mapped to a MARC subfield, The Items still not loading. I've been searching and the only place where I find biblioitems.itemtype is 942, so I will try to insert that field in the frameworks.
I've inserted the 942$c and the Famework test is OK: OK biblioitems.itemtype defined I've run: search_for_data_inconsistencies.pl batchRebuildBiblioTables.pl -c rebuild_zebra.pl -b -r -v and everything ik OK without errors. The "Processing" problem don't go away... The Chromium devtools have the error on the attached image. Probably it is something related with "homebranch"
Created attachment 170131 [details] Dev_tools_homebranch_error
Permanent_location is not the homebranch, but the permanent_location in your items table. It should automatically be set to the location. Did you migrate data at some point? Could you check if that is empty in your installation? For a test it would be great if you could edit the items, change location, save, change it back, save - so we can see if that fixes the issue.
First I checked de DB to see what is on items.location and items.permanent_location. Both fields were (NULL) Then I've made 2 tests: 1 - Edit the item, change location, save. Check the DB: homebranch and holdingbranch changed to the values I've set. items.location and items.permanent_location still NULL. Change it back, save. Check the DB: homebranch and holdingbranch changed to values I've set. items.location and items.permanent_location still NULL. The "Processing" persists... 2 - Manually change in the DB the items.location and items.permanent_location to the homebranch The "Processing" persists...
NULL should not have been a problem, but a homebranch code is wrong. These columns would usually be set to a value from the authorised value category LOC.
Tried with Values from LOC table but makes no difference...
(In reply to José Anjos from comment #25) > Tried with Values from LOC table but makes no difference... Yes, I think we possibly some bug here, we are still trying to figure out things. Calling in some reinforcements (CC list).
I tried again to change biblionumber and biblioitemnumber to the suggested on: UNIMARC MARC 21 995$b 952$a branchcode items.homebranch owning library 995$c 952$b branchcode items.holdingbranch holding library (usu. the same as 952$a ) I also reviewed all the frameworks according: https://koha-community.org/manual/latest/en/html/cataloging.html#cataloging-guides and https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx) Finally the MARC bibliographic framework test says: You don't have errors in your MARC configuration Yey!! Then I did another test: ./batchRebuildBiblioTables.pl -c Everything OK Tried load Record with biblionumber=76650, NOT OK Edit Record, Save. Edit Item, Save. ./rebuild_zebra.pl -b -r -v --where biblionumber='76650' Tried load Record with biblionumber=76650, NOT OK In addition to the error shown above (https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170131), in the Dev Tools, several lines with error point to: Uncaught TypeError: row._strings.location is undefined render https://library-staff.library.test/cgi-bin/koha/catalogue/detail.pl?biblionumber=76650:3292 get https://library-staff.library.test/intranet-tmpl/lib/datatables/datatables.min_24.0502000.js:41
I'd recommend undoing the changes you did to your biblionumber and biblioitemnumber configuration. The problem is that changing the frameworks doesn't change your data. So now Zebra looks for the biblionumber in the record in the wrong field. It's also unlikely that this is causing your display issues if search etc. worked OK before. I hope we can get some more ideas on this next week.
Katrin Fischer, The data doesn't change after doing re rebuilds? ./batchRebuildBiblioTables.pl -c ./rebuild_zebra.pl -b -r -v Where is the data that doesn't change? Thank you for your advise.
(In reply to José Anjos from comment #29) > Katrin Fischer, > The data doesn't change after doing re rebuilds? > ./batchRebuildBiblioTables.pl -c > ./rebuild_zebra.pl -b -r -v > > Where is the data that doesn't change? > Thank you for your advise. When you change the mappings for your biblionumber in the framework, that only updates the framework. In your MARC records in the database, the record is still in the previous field. Only when you add a new record or edit it, the new framework default would be used. So there is a big danger here for creating inconsistent data that will cause many issues. I believe > ./batchRebuildBiblioTables.pl -c doesn't do the trick here as the error on indexing shows. It updates the data in biblio, biblioitems and items, according to the mappings, but not your MARC data. Say you changed biblionumber from 001 to 999. In your MARC record it's still in 001, but the configuration tells Zebra to look in 999 - resulting in broken indexing. Hope that explains.
I can confirm this is a 24.05 problem. I've upgraded my test VM from 23.05 to 24.05 and the Item list get stuck on loading to.
(In reply to José Anjos from comment #31) > I can confirm this is a 24.05 problem. > I've upgraded my test VM from 23.05 to 24.05 and the Item list get stuck on > loading to. Yes, the API driven view is a new feature in 24.05.
i had the same issues.... Just upgraded from 23.11.04 kepada Koha 24.05.03... Please koha admin, solve this problem
See Bug 37416 - Holdings table errors or stuck on "Processing" in the staff interface - how to identify cause and possible solutions (comment 19) for some more things to look at as possible causes: - Check the 'item-level_itypes' system preference setting - Review any plugins that you have, or temporarily disable
Thanks for the suggestions. Changed item-level_itypes' system preference setting to "bibliographic record" Result: Before, it keeps stuck on "processing". Now I get the message: Something went wrong when loading the table. 500: Internal Server Error. I just have the Flowcover plugin but I disable it anyway, but makes no difference. I want to add this information: This bug is just on STAFF interface. On OPAC the Items are displayed.
Regarding the "location" and the error "row._strings.location is undefined", my guess is that the location is not mapped to an authorised value category. Could you confirm/unconfirm that please? Go to admin/marc_subfields_structure.pl?op=add_form&tagfield=952&frameworkcode=#subcfield (if you are using the default framework, otherwise adjust the frameworkcode in the URL) and let us know if you have something selected in the "Authorized value:" dropdown list.
Created attachment 170769 [details] [review] Bug 37544: Prevent the item table to crash if location is not linked with an av cat If location (952$c) is not linked with an authorisd value category, the item table won't load and will crash with "row._strings.location is undefined" in the JS console. Is it mandatory to have it linked?
Created attachment 170770 [details] [review] Bug 37544: Prevent the item table to crash if ccode is not linked with an av cat Same as the previous patch for collection_code (952$8)
Those 2 patches should fix the problem I have identified in the code, that could lead to this problem. But I am not sure if it's a configuration problem or not.
*** This bug has been marked as a duplicate of bug 37375 ***