October 2024 - Koha-bugs - lists.koha-community.org

[Bug 38225] New: Catalog statistics report shows incorrect total when library has both blank and null values in an item column
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38225 Bug ID: 38225 Summary: Catalog statistics report shows incorrect total when library has both blank and null values in an item column Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Browse to Reports->Catalog 2 - Set columns = homelibrary = Centerville 3 - Set row = Collection 4 - Set Cell Value to Count total items 5 - Set Output to To the screen 6 - Run, note columsn match 7 - Change some values in the DB: UPDATE items SET ccode="" WHERE ccode='REF' and barcode LIKE '%35'; 8 - Run report again, off by one 9 - Edit the code in the script and set: our $debug=1 10 - Copy the code from the logs and add the library, or run the command below where I did that already: SELECT items.ccode, items.homebranch, COUNT(*) FROM items LEFT JOIN biblioitems ON (items.biblioitemnumber = biblioitems.biblioitemnumber) LEFT JOIN biblio ON (biblioitems.biblionumber = biblio.biblionumber) WHERE 1 AND items.homebranch LIKE 'CPL' group by items.ccode, items.homebranch order by items.ccode,items.homebranch; 11 - Note the row with no value and total 5 - it is missing on the report in the interface, instead NULL has been shown twice - the value overwritten and causing a mismatch in totals -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 5387] Support for NISO CORE: Cost of Resource Exchange Protocol
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5387 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WISHLIST Status|ASSIGNED |RESOLVED --- Comment #3 from David Cook <dcook(a)prosentient.com.au> --- I'm going to close this one since MJ Ray isn't around anymore. But I'll leave it as a WISHLIST as it sounds interesting... -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 5387] Support for NISO CORE: Cost of Resource Exchange Protocol
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5387 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #2 from David Cook <dcook(a)prosentient.com.au> --- Interesting. I wonder if this protocol ever got used. It looks like it was primarily a SOAP-based protocol, which wouldn't be very common anymore... -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 5387] Support for NISO CORE: Cost of Resource Exchange Protocol
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5387 Martin Renvoize (ashimema) <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize(a)ptfs-europe.com> --- Wow, I've never heard of this and yet to come across a product that supports it or asked for it's used. Shame, it sounds like a decent idea. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 36898] New: Elasticsearch indexer error log needs more information
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36898 Bug ID: 36898 Summary: Elasticsearch indexer error log needs more information Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au Fairly regularly I'm seeing the following message showing up in /var/log/koha/instance/es-indexer-output.log [2024/05/20 09:28:13] [WARN] Update of elastic index failed with: Exception 'Koha::Exceptions::Elasticsearch::BadResponse' thrown 'Bad response received when submitting request to Elasticsearch' with details => [https://hostname:9300]-[599] Timed out while waiting for socket to become ready for reading, type => Timeout main::catch {...} /usr/share/koha/bin/workers/es_indexer_daemon.pl (229) But this doesn't really tell me anything useful. It's not clear what records failed to update or what the job number was, so there's no way to re-try and fix the missing indexed data. Also, I've updated the request_timeout from 30 to 60, so it's a fairly long timeout. Generally speaking, there was a fair amount of indexing activity, but around 09:27:13 there wasn't. Although there was 6 jobs at 09:28:13, so maybe it's not the request_timeout that needs tweaking... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 14007] Item types for items hidden by OpacHiddenItems turn up in facet results
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|andreas.jonsson(a)kreablo.se |dcook(a)prosentient.com.au Status|In Discussion |ASSIGNED --- Comment #25 from David Cook <dcook(a)prosentient.com.au> --- I'm going to take this one over. I've got a library who wants this fixed, and I've got an idea on how to do it, so planning to do this soon. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37481] New: Some operations that do not affect data should be submitted as POST requests
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37481 Bug ID: 37481 Summary: Some operations that do not affect data should be submitted as POST requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Summarizing from bug 37197: There are limits to URL size that make POST preferable to GET in some instances. We can handle this with fake cud- operations "cud-show" or by allowing "show" and "cud-show" options to do the same things We have links that append the data - these could be made to use our new JS form submission We need to decide on a path here -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37614] New: Printing patron cards from patron lists broken by CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37614 Bug ID: 37614 Summary: Printing patron cards from patron lists broken by CSRF protection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, oleonard(a)myacpl.org Blocks: 36192 Steps to reproduce: 1. Tools - Patrons lists, if you don't already have one then New list, name and save, Search for patrons, add at least one patron, then return to Patron lists. 2. In the Actions menu for your patron list, select Print patron cards 3. In that perfectly normal looking popup, click Export. You now have a popup with an Loading throbber, which will hang forever, and in your console you have a 403 error from trying to GET patroncards/print.pl. If you go back and inspect the page where you clicked Export, you'll find that it is a button type='submit' in a form with method='post' which makes the GET seem a bit odd. To see that it sometimes posts, 1. Tools - Patron card creator - New card batch - Add at least one patron 2. Export card batch 3. You get a popup with a lovely Windows 95 aesthetic courtesy of greybox.inc, but it is that same form method='post' with the same type='submit' Export button. Click Export and you will POST to patroncards/print.pl and things will work just fine. Not at all clear to me how opening the popup one way turns the POST to a GET, but it does. There's a FIXME in patroncards/print.pl saying that the op=cud-export looks sus, which it does. You could try to make the case that it's sensible to POST because in the case where you have selected some but not all of the patrons in a label batch, the number of label_id params in the URL could be so high that it exceeds Apache's max URL length, but then the result of the POST is a link to create the PDF that is the actual "print" export, and that link is a GET which contains all of them with an over-escaped &label_id= param for each one. So a pragmatic fix would be to just change from a POST to a GET, change cud-export to export, and not worry about why called one way it POSTs and called another way it GETs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 7012] Limit to available does not exclude in-transit items
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7012 --- Comment #20 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #9) > Elasticsearch and Zebra both index MARC. So bibliographic records and items. Technically, I don't think that's 100% true. We've made the search engines MARC-focused with Koha, but they don't have to be. We process MARC records and turn them into JSON document for Elasticsearch. We pass MARCXML records to zebraidx for Zebra, but technically we should be able to wrap the MARCXML with our own "Koha XML" and inject whatever we want. I don't think that this was possible with GRS-1 indexing but it should be with the DOM indexing. But the tricky part isn't the indexing. It's managing the state in the database across a huge range of Perl functions. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7012] Limit to available does not exclude in-transit items
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7012 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #19 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Martin Renvoize (ashimema) from comment #14) > This is the sort of thing I'd love to see the foundation sponsor once it's > setup.. we all agree it's a bug and should be fixed, we just can't easily > prioritise it individually when we have bills of our own to pay. I think one of the problems here is also agreeing on a design. Joubu linked me to bug 7012 from bug 38181 as I point out the performance problems with calculating item status using the ORM item by item at search time. Bug 37334 will suffer from the same problem as bug 38181. Off the top of my head, we need to be storing the status in the database and indexing that. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0