July 2025 - Koha-bugs - lists.koha-community.org

[Bug 31256] New: Circ rules batch modification
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31256 Bug ID: 31256 Summary: Circ rules batch modification Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Wouldn't it be nice if you could batch modify rules? Like, I have to set a hard due date for schools each year. Instead of modify each rule individually, it would be great if I could specify all libraries, or specific ones, all rules under that or specific ones, and what I would change. There are times when we have to change the fines to everything, or change the holds to many rules, etc. This would make this job so much easier. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 31971] New: SIP server rejects passwords ending in non-alphanumeric characters
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31971 Bug ID: 31971 Summary: SIP server rejects passwords ending in non-alphanumeric characters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Set a patron's password to secret* 2 - Attempt a patron information request via the sip clip emulator: perl misc/sip_cli_emulator.pl -su term1 -sp term1 -l CPL -a localhost -p 6001 -m patron_information --patron ballard --password secret* 3 - It fails? 4 - Set password to secret*s 5 - Repeat perl misc/sip_cli_emulator.pl -su term1 -sp term1 -l CPL -a localhost -p 6001 -m patron_information --patron ballard --password secret*s 6 - It succeeeds Offending line(s) appears to be: 366 $buffer =~ s/^\s*[^A-z0-9]+//s; 367 # Every line must start with a "real" character. Not whitespace, control chars, etc. 368 $buffer =~ s/[^A-z0-9]+$//s; 369 370 # Same for the end. Note this catches the problem some clients have sending empty fields at the end, like ||| -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 30653] New: "Check out" search with one result does not redirect to checkout
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30653 Bug ID: 30653 Summary: "Check out" search with one result does not redirect to checkout Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I am seeing this on 21.11.04. I go to the front page of the intranet. The "Check out" tab of the header search is active as default. I type my name into the search box and press enter. This takes me to this page: /cgi-bin/koha/members/member.pl?quicksearch=1&circsearch=1&searchmember=magnus%20enger This page shows one result, and the "Card" column links to: /cgi-bin/koha/circ/circulation.pl?borrowernumber=1 while the "Name" column links to: /cgi-bin/koha/members/moremember.pl?borrowernumber=1 If I choose my name in the typeahead/dropdown that appears below the search box, I am taken to this page: /cgi-bin/koha/circ/circulation.pl?borrowernumber=1 Then I do the same thing in 21.05.05: Type my name in the "Check out" box and press Enter. There I am taken directly to: /cgi-bin/koha/circ/circulation.pl (This is a POST, so borrowernumber=1 is not visible in the URL). Looking more closely at the source of /cgi-bin/koha/members/member.pl?quicksearch=1&circsearch=1&searchmember=magnus%20enger in 21.11.04 I do see this: $.ajax({ 'dataType': 'json', 'type': 'POST', 'url': sSource, 'data': aoData, 'success': function(json){ // redirect if there is only 1 result. if ( json.aaData.length == 1 && aoData.iDisplayStart == 0 ) { var borrowernumber = json.aaData[0].borrowernumber; /* Overwrite history state of firstletter search since only one result was returned; This prevents a loop upon clicking back */ history.replaceState( {}, null, window.location.href.split("?" )[0]); document.location.href="/cgi-bin/koha/circ/circulation.pl?borrowernumber="+borrowernumber; return false; } fnCallback(json); } }); This seems to incorporate the fix from bug 29411, but it does not seem to be working. There is nothing in the console. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40487] New: If you edit "Sort this list by" for a list, it gets stuck on publicationyear
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40487 Bug ID: 40487 Summary: If you edit "Sort this list by" for a list, it gets stuck on publicationyear Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the staff interface, if you edit a list and try to change the sort by choosing an option from "Sort this list by", it gets changed to "Publication year" instead of your selection, and it becomes permanently stuck with this sort. As noted on bug 40312, the sort for the list contents also doesn't work. For instance, if it's the default "Title", it seems to be sorting by biblionumber ascending. (Note that this sort order doesn't affect the sort order for the OPAC list contents but it might not have ever worked for it anyway) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25767] New: Add Koha::Item::Transfer->receipt method
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25767 Bug ID: 25767 Summary: Add Koha::Item::Transfer->receipt method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We should have a `receipt` method on the Koha::Item::Transfer object to allow marking the item as received and the transfer as complete. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 36372] New: Allow privileged users to set the 'record source' on cataloguing
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36372 Bug ID: 36372 Summary: Allow privileged users to set the 'record source' on cataloguing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This would be handy, as right now it can only be set through an API request. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 69

[Bug 37381] New: Suggestion mandatory fields needed in staff interface
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37381 Bug ID: 37381 Summary: Suggestion mandatory fields needed in staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It is possible to mark fields mandatory in the purchase suggestion form for the OPAC with OPACSuggestionMandatoryFields. It should also be possible to mark fields mandatory for the purchase suggestion form in the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 27637] New: Allow ReservesMaxPickUpDelay to be adjusted based on item values
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27637 Bug ID: 27637 Summary: Allow ReservesMaxPickUpDelay to be adjusted based on item values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref ReservesMaxPickUpDelay contains a number of days to be added to the current date in order to derive the expiration date for a hold. It allows no variation for item types, libraries, etc. I propose a new companion syspref of ReservesMaxPickUpDelayAdjustments (or something). It'd take a set of item table fields, values, and numbers to be added to the ReservesMaxPickUpDelay value. So something like: holdingbranch: CPL: 2 itype: DVD: -3 Would mean holds on items at CPL would get 2 extra days, holds on DVDs would get 3 fewer days. Whatever syntax we arrive at should allow grouping conditions, so a library could adjust pickup delays for only a specific itype at a specific branch, for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 35886] New: FindDuplicate only checks first ISBN
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35886 Bug ID: 35886 Summary: FindDuplicate only checks first ISBN Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When ordering a title via z39.50, the duplicate match is only done on the first ISBN. This can lead to duplicates being ordered and created. To recreate: 1. Have a record that you can find via z39.50 2. Copy the ISBN 3. In Acquisitions, create a basket 4. Add to basket from an external source 5. Using the copied ISBN, search a z39.50 source 6. Click the result and click Order --> It should warn for a duplicate 7. Click Cancel 8. Edit the record, add a second ISBN 9. Redo steps 4-6 --> It should warn for a duplicate 10. Click Cancel 11. Edit the record, place the second ISBN in first position 12. Redo steps 4-6 --> No duplicate warning! Note: if you cancel after step 12, the duplicate record will have been created. You will need to search your catalog and delete the record to redo the tests. I don't know if that is only in the case of z39.50 or if other types of orders also have that same problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 28965] New: Add public routes for lists
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28965 Bug ID: 28965 Summary: Add public routes for lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 53