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

[Bug 14962] Temp Shelving Location
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '26

07 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Lauren Denny <lauren_denny(a)sil.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lauren_denny(a)sil.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37843] New: No logs for any errors when trying to connect to remote SRU/z39.50 server
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '26

07 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37843 Bug ID: 37843 Summary: No logs for any errors when trying to connect to remote SRU/z39.50 server Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #207 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Nice work everyone! Pushed to main for 26.05 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41792] New: Circulation rules entry count always +1
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41792 Bug ID: 41792 Summary: Circulation rules entry count always +1 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The circulation and fine rules grid begins with a "Showing 1 to X of X entries" counter, but the X count is always one too high. The counter seems to include the blank add/edit entry line at the bottom of the grid in the count. This should not be counted as if an actual entry in the rules. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41791] New: Better on-screen feedback when recording local use
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41791 Bug ID: 41791 Summary: Better on-screen feedback when recording local use Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Currently, when recording a local use with a statistical patron in Koha, the only feedback on the screen after scanning a barcode is "Local use recorded". We would like to see information on the last item processed somewhere on screen. Our staff typically log local uses in batches (hourly collection of books off carts and tables), and it is easy to lose your place if interrupted. Knowing the last item scanned would be very helpful to maintaining accurate local use statistics. A message like "Local use recorded for ...." would be ideal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41790] New: Add an option to automatically prepend "+1" to smsalertnumber
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41790 Bug ID: 41790 Summary: Add an option to automatically prepend "+1" to smsalertnumber Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: eric(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With integrations with services like Twilio that require the +1 it would be nice for that to be prefilled so that staff would not need to remember to do that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41784] New: Item circ history 'last seen' updates at 2 branches when checked out at one branch and returned at another
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41784 Bug ID: 41784 Summary: Item circ history 'last seen' updates at 2 branches when checked out at one branch and returned at another Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com If an item is checked in at a branch different than the branch it was checked in at, the 'last seen' for both branches will be updated, even though it was only seen at one branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 41787] New: Serial claims: exporting late issues with the CSV profile set the issue claimed
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41787 Bug ID: 41787 Summary: Serial claims: exporting late issues with the CSV profile set the issue claimed Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When using the CSV export option for late serial issues, issues status is set to claim. Some libraries would prefer that the status is not changed (and to manually change the status once they have actually claimed it). As this behavior was added as a bug fix in Bug 12178 I suggest that we add an option to let librarian choose whether they what to change the status when downlanding the file or not. Maybe a checkbox to allow choosing if we want to update the status or not ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 28833] New: Speed up holds queue builder via parallel processing
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28833 Bug ID: 28833 Summary: Speed up holds queue builder via parallel processing 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The holds queue builder can take a very long time to run on systems with many holds. For example, a partner with 124,784 unfilled ( not found ) holds, is taking about 64 minutes to run. If we run that same number of holds in 5 parallel chunks ( splitting the number of records as evenly as possible, but *not* taking into account the holds per bib ), it takes 21.5 minutes. If we use 10 loops, it takes less then 14 minutes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50