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

[Bug 34132] New: Undo batch Item modification
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

01 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34132 Bug ID: 34132 Summary: Undo batch Item modification 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl >From background_jobs.pl there could be a button to undo or reverse a batch item modification -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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 36372] New: Allow privileged users to set the 'record source' on cataloguing
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '25

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