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

[Bug 28527] New: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Bug ID: 28527 Summary: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a transfer is cancelled whilst it is in transit (datesent set, but datearrived not) then we should still return it as in transit. Bug 27993 added a condition to the 'in_transit' boolean which should be reverted. We should also update the get_transfer (and get_transfers) methods to catch such cases and return those still active transfers and deal with them appropriately at check-in. (i.e. invoke the reverse transfer or pick the next transfer from the queue and notify the librarian of what subsequent actions they should take). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 42296] New: Tidy all script tags - trivial ones
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42296 Bug ID: 42296 Summary: Tidy all script tags - trivial ones Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42094 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 [Bug 42094] Tidy all script tags (except value_builder) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 43288] New: Change amount missing from printed fee receipts (change_given/change param mismatch)
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43288 Bug ID: 43288 Summary: Change amount missing from printed fee receipts (change_given/change param mismatch) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- members/pay.tt, members/paycollect.tt, and members/boraccount.tt all open members/printfeercpt.pl with a change_given= query parameter after taking a payment (for the FinePaymentAutoPopup auto-printed receipt, and for the manual Print action). However printfeercpt.pl only ever reads a 'change' param into its GetPreparedLetter substitute hash: substitute => { tendered => scalar $input->param('tendered'), change => scalar $input->param('change') } This matches the default ACCOUNT_CREDIT/CREDIT_PAYMENT notice templates, which use [% change | $Price %] (not change_given). Since nothing ever sends a change= param, the Change line on every printed fee receipt is silently blank. This isn't new: installer/data/mysql/db_revs/220600072.pl shows Koha previously migrated stored ACCOUNT_CREDIT letter content from [% change_given to [% change, so 'change' is the established name on the notice-template side. This patch fixes the three query strings that build the printfeercpt.pl URL to send change= instead of change_given=, rather than touching printfeercpt.pl or notice content. The change_given variable name is left alone everywhere else (hidden form fields, JS locals, Perl params) - this is purely about the query key at the printfeercpt.pl boundary. Test plan: 1. Set the FinePaymentAutoPopup system preference to "show" 2. Take a payment for a patron (via members/pay.pl or members/paycollect.pl) for less than the full amount tendered, so change is generated 3. Note the auto-popped-up receipt's Change line is blank 4. Apply the patch 5. Repeat step 2 6. Note the Change line now shows the correct amount 7. Repeat via the boraccount.pl account tab's Print action for a payment with change -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 43269] New: Add cached description_for() class methods to Koha::Libraries, Koha::ItemTypes, Koha::Patron::Categories
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43269 Bug ID: 43269 Summary: Add cached description_for() class methods to Koha::Libraries, Koha::ItemTypes, Koha::Patron::Categories Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Several places in Koha need to resolve codes to human-readable descriptions (branchcode to library name, categorycode to category description, itype to item type description). Currently this is done either per-row via Koha::Libraries->find($code)->branchname (uncached, N+1 queries) or via C4::Biblio::GetAuthorisedValueDesc (cached but MARC-centric API requiring tag/subfield/framework). We should add cached class-level lookup methods on the domain objects: Koha::Libraries->name_for($branchcode); Koha::Patron::Categories->description_for($categorycode); Koha::ItemTypes->description_for($itype); These would: - Use Koha::Caches to pre-fetch all values for the table on first access - Return the description string (or the raw code as fallback) - Be usable from any context (CSV exports, templates, scripts, REST API) This decouples the caching from the MARC layer and makes it available to the Koha::CSV subclass pattern (bug 41621) and anywhere else that needs bulk code-to-description resolution without N+1 queries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 42399] New: Update some tools pages to use grid layout for forms - Part 2
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42399 Bug ID: 42399 Summary: Update some tools pages to use grid layout for forms - Part 2 Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 41823 - Tools -> Notices and slips - Tools -> Batch patron modification - Tools -> Upload patron images - Tools -> Quote editor - Tools -> Task scheduler - Tools -> Uploads - Tools -> Log viewer - Cataloging -> Stage MARC records for import - Cataloging -> Manage staged MARC records - Cataloging -> Stock rotation Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41823 [Bug 41823] Update acquisitions admin pages to use grid layout for forms -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 41313] New: When querying for available pickup locations for a biblio, invalid choices are provided
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41313 Bug ID: 41313 Summary: When querying for available pickup locations for a biblio, invalid choices are provided Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When branch transfer limits are in use, the call to /biblios/[id]/pickup_locations gives available pickup locations for all items, regardless of the holdability of the items. This can lead to have wrong choices provided by the api. Since reserve/request.pl also rely on the api to display the available pickup location this can lead to show record-level hold as possible with some available pickup locations although no items are available due to branch transfer limits. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 10993] Transfer limits should be checked when placing a hold/reservation in OPAC.
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10993 Serhij Dubyk <dubyk(a)ukr.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dubyk(a)ukr.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 41768] New: OPAC pickup location selector doesn't reflect available pickup location if you select a specific item
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Bug ID: 41768 Summary: OPAC pickup location selector doesn't reflect available pickup location if you select a specific item Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org As of now, if I go on the OPAC to place a hold, I'm presented a list of available pickup locations for that biblio. However, If I click on "more options" and select a specific item with limited transfers, I can still select any pickup location available for the biblio. This leads to a user being able to select a pickup location and be denied the hold request only after confirmation, and then have to restart again (without knowing which libraries will work). I think that can lead to some frustration for users. This is quite similar to BZ33302 or BZ10993 but I will provide a new patch with the use of Koha's api and make the OPAC more similar to the intranet interface. -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 31391] New: Staff-side recalls
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31391 Bug ID: 31391 Summary: Staff-side recalls 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Add functionality for recalls to be placed via the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 312