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

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | --- Comment #568 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- follow-up pushed to main -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35746] New: Multiple selections for parameters used in the IN function
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35746 Bug ID: 35746 Summary: Multiple selections for parameters used in the IN function Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if when a dropdown selection is used in something like an IN statement in WHERE, that Koha would allow you to select multiple options. So, for example: WHERE branchcode IN (<<branches>>) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 70

[Bug 40975] New: Long library name overflows patron brief info
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40975 Bug ID: 40975 Summary: Long library name overflows patron brief info Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 187590 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187590&action=e… Library name overflows borders of left menu panel To replicate: 1. Create a library branch with a really long name (my example was 34 characters and spaces), 2. Edit a patron and assign them to the new branch. 3. View the patron brief info and see that the name overflows the left menu panel border (attached image). The behavior seems to depend on the page scale. I can see the name overflow when the browser is zoomed in at 100%. If I zoom in further, say 125%, the name does not overflow. If I zoom out to 90%, it does not overflow. It also may be browser dependent. Seems to be a problem on Brave (Chromium based) and Chrome, but not Firefox. Observed on Brave 1.83.109 (Official Build) (64-bit), Chromium: 141.0.7390.55 and Chrome Version 128.0.6613.113 (Official Build) (64-bit) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 37077] New: SQL Reports - Picking only one option for each multiple selection results in wrong query
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37077 Bug ID: 37077 Summary: SQL Reports - Picking only one option for each multiple selection results in wrong query Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: andrewfh(a)dubcolib.org, blawlor(a)clamsnet.org, caroline.cyr-la-rose(a)inlibro.com Depends on: 35746 To reproduce: 1. Go to Reports and create a report from SQL select * from items where homebranch in <<Libraries|branches:in>> and itype in <<Item type|itemtypes:in>> 3. Run the report but pick only 1 library and 1 item type 4. Click the "Show SQL code" 5. Notice itype value is wrong. It's using the same value selected for library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35746 [Bug 35746] Multiple selections for parameters used in the IN function -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 35856] New: Runtime parameter modal should provide option of ":all"
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35856 Bug ID: 35856 Summary: Runtime parameter modal should provide option of ":all" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: lucas(a)bywatersolutions.com, nick(a)bywatersolutions.com Depends on: 35746 The modal interface to insert a runtime parameters should offer the option to make one's parameter offer the "All" option. Currently, use of the All feature requires one to manually add ":all" at the end of the parameter and is not clearly suggested by anything in the interface. The modal could include a checkbox one could check to add ":all" to the constructed parameter. It would probably be helpful to display some text reminding the user that one must use LIKE rather than = with ":all." I've made this depend on bug 35746, which adds an ":in" option. If that gets pushed, it'd be great to have it included as an option in the modal, too. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35746 [Bug 35746] Multiple selections for parameters used in the IN function -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #567 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Created attachment 187587 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187587&action=e… Bug 15516: (follow-up) DBRev nneds to include everything from the kohastructure -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40729] New: manual credits appear as income in the POS
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40729 Bug ID: 40729 Summary: manual credits appear as income in the POS Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org When creating a manual credit for a patron, it's appearing as income in the POS transaction history. To recreate 1. Make sure POS is on and you have a register set up. 2. Create a manual credit of some amount. 3. Go the transaction history of the register and notice that your drawer appears to have more money in it than it should. 4. Pay out the credit. 5. Look at the transaction history. Note that the credit is paid out properly. What this means is that if I create a manual credit of $5 and give the person the cash, the drawer should show as $5 less than it had, but right now it shows as having the same amount because the income offsets the amount paid out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40974] New: Replace acqui/check_uniqueness.pl with REST API
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40974 Bug ID: 40974 Summary: Replace acqui/check_uniqueness.pl with REST API Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Surely we can now replace old-fashion acqui/check_uniqueness.pl with REST API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 40973] New: Redirect to configurable destination after Shibboleth logout
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40973 Bug ID: 40973 Summary: Redirect to configurable destination after Shibboleth logout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We have a scenario where we have disabled OpacPublic, and set OPACShibOnly = Don't allow. This means that when users visit the OPAC they are immediately sent to the idP for login. This works great. The problem is when they try to logout, because after logging out they are sent back to the OPAC, where they are automatically logged in again, if they are still logg in to the idP. This means users can be caught in a loop, with no possibility of getting logged out of Koha. This is the code in C4::Auth_with_shibboleth that returns users to the OPAC after logout: # Logout from Shibboleth sub logout_shib { my ($query) = @_; my $uri = _get_uri(); my $return = _get_return($query); print $query->redirect( $uri . "/Shibboleth.sso/Logout?return=$return" ); } (_get_uri basically returns staffClientBaseURL or OPACBaseURL, as appropriate) To get around this we would like to propose that logout_shib could() send users to a configurable location, outside of Koha, based on a syspref. Something like this: # Logout from Shibboleth sub logout_shib { my ($query) = @_; my $uri = _get_uri(); my $return; if ( C4::Context->preference('ShibRedirectURLAfterLogout') ) { $return = C4::Context->preference('ShibRedirectURLAfterLogout'); } else { $return = _get_return($query); } print $query->redirect( $uri . "/Shibboleth.sso/Logout?return=$return" ); } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36835] New: Add a way to get a local cover image from biblionumber
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36835 Bug ID: 36835 Summary: Add a way to get a local cover image from biblionumber Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I don't think there is currently an API route for getting a local cover image (stored by Koha) from the biblionumber of the record It could be useful -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6