November 2022 - Koha-bugs - lists.koha-community.org

[Bug 30274] New: Non-reservable items should only fill item-level reserves
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '25

02 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30274 Bug ID: 30274 Summary: Non-reservable items should only fill item-level reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For item types where 'holds allowed(total)' equals 0, you can still place reserves on these non-reservable items via the staff client by overriding the circulation rule. The bug is that, when you check in an item that is non-reservable (holds allowed is 0), it will trigger the holds pop-up and can fill a biblio-level hold ("next available"). The holds pop-up should only be triggered by non-reservable items if there is an item-level reserve on it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 23581] New: Do not fill hold when patron account has overdues/fines
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '25

02 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23581 Bug ID: 23581 Summary: Do not fill hold when patron account has overdues/fines Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Would like to see a preference that would keep a patron from advancing and/or having holds filled in the queue if they have overdue items and/or fines. This could be used as an incentive to return items on time and not play the system in some ways, especially in libraries that don't charge fines. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28500] New: Display before and after values when a biblio has been edited
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28500 Bug ID: 28500 Summary: Display before and after values when a biblio has been edited Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Trying to determine what information was changed in a biblio is rather difficult. While there is some functionality in the logs, not all staff have access to the logs, nor is the info easy to interpret. It would be really helpful to have another method of tracking changes to bib records, such as a simple BEFORE value: xxxx AFTER value: xxxxx that only records the changes made, which user made the change, and when. Ideally this would be viewable outside of logs, perhaps through reports, and kept for the entire time the biblio is in the catalog. This is very important for libraries that have multiple locations and multiple staff editing biblios - there is a need to see who made what changes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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 25767] New: Add Koha::Item::Transfer->receipt method
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '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 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 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

[Bug 19762] New: PREDUE notices should be not applied when OverdueNoticeCalendar is activate
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '25

29 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19762 Bug ID: 19762 Summary: PREDUE notices should be not applied when OverdueNoticeCalendar is activate Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, It would be great if the OverdueNoticeCalendar systeme preference could be set for the PREDUE notices too. For exemple a student receive his predue notices for document on saturday, but the library is closed for the week end, this student should not had receive this notification on saturday because it cause misunderstanding. It cause so many incomprehension for the user to receive this notifications when the library is closed. So, if the OverdueNoticeCalendar could take into consideration this notification too it would more understandable for students. Or, it could be an option. Patrick. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10