[Bug 37544] New: Item table not loading on Normal View, after upgrade
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Bug ID: 37544 Summary: Item table not loading on Normal View, after upgrade Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: joseanjos@gmail.com QA Contact: testopia@bugs.koha-community.org Created attachment 169943 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169943&action=edit 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 José Anjos <joseanjos@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - low |P2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Angela Berrett <angela.berrett@familysearch.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |angela.berrett@familysearch | |.org --- Comment #1 from Angela Berrett <angela.berrett@familysearch.org> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #2 from Angela Berrett <angela.berrett@familysearch.org> --- Created attachment 169965 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169965&action=edit Holdings 500 error -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37375 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |33568 CC| |david@davidnind.com See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37416 --- Comment #4 from David Nind <david@davidnind.com> --- 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? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 [Bug 33568] Use the REST API to display items on the biblio detail view -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #5 from José Anjos <joseanjos@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- The update didn't change the frameworks, but the new display for items is a bit more picky if definitions are missing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #7 from José Anjos <joseanjos@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #8 from José Anjos <joseanjos@gmail.com> --- Created attachment 170006 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170006&action=edit Framework test NOT OK -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #10 from Angela Berrett <angela.berrett@familysearch.org> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #12 from Angela Berrett <angela.berrett@familysearch.org> --- 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! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #13 from David Nind <david@davidnind.com> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #15 from Angela Berrett <angela.berrett@familysearch.org> --- Okay - I spent yesterday pulling lists of everything and will start the cleanup today. Thank you for helping me figure all of this out! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #16 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #17 from Angela Berrett <angela.berrett@familysearch.org> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #18 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #19 from José Anjos <joseanjos@gmail.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #20 from José Anjos <joseanjos@gmail.com> --- 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" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #21 from José Anjos <joseanjos@gmail.com> --- Created attachment 170131 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170131&action=edit Dev_tools_homebranch_error -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #22 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #23 from José Anjos <joseanjos@gmail.com> --- 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... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #24 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #25 from José Anjos <joseanjos@gmail.com> --- Tried with Values from LOC table but makes no difference... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m, | |nick@bywatersolutions.com, | |tomascohen@gmail.com Keywords| |RM_priority --- Comment #26 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #27 from José Anjos <joseanjos@gmail.com> --- 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-... 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?biblionu... get https://library-staff.library.test/intranet-tmpl/lib/datatables/datatables.m... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #28 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #29 from José Anjos <joseanjos@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #30 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #31 from José Anjos <joseanjos@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #32 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Jimmy <azmikhalib@utm.my> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |azmikhalib@utm.my -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #33 from Jimmy <azmikhalib@utm.my> --- i had the same issues.... Just upgraded from 23.11.04 kepada Koha 24.05.03... Please koha admin, solve this problem -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #34 from David Nind <david@davidnind.com> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #35 from José Anjos <joseanjos@gmail.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #36 from Jonathan Druart <jonathan.druart@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #37 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 170769 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170769&action=edit 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #38 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 170770 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170770&action=edit 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) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 --- Comment #39 from Jonathan Druart <jonathan.druart@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #40 from Jonathan Druart <jonathan.druart@gmail.com> --- *** This bug has been marked as a duplicate of bug 37375 *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|RM_priority | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37544 Bug 37544 depends on bug 33568, which changed state. Bug 33568 Summary: Use the REST API to display items on the staff biblio detail view https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org