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

[Bug 41633] New: Add Koha::CSV::Framework for framework exports
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41633 Bug ID: 41633 Summary: Add Koha::CSV::Framework for framework exports 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 Depends on: 41619 Blocks: 41621 This bug adds Koha::CSV::Framework to standardize CSV generation for MARC framework exports. Files to update: - C4/ImportExportFramework.pm Benefits: - Consistent CSV formatting - Proper quote handling - Testable code Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41619 [Bug 41619] Add `Koha::CSV` https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41621 [Bug 41621] Use Koha::CSV everywhere [UMBRELLA] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41619] New: Add `Koha::CSV`
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41619 Bug ID: 41619 Summary: Add `Koha::CSV` Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 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 I propose we add a wrapper class on top of `Text::CSV` that takes care of applying all the required settings we might need. It should provide a way to override those settings (e.g. separator character, formula, etc). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 42857] New: AddReturn early returns skip transfer processing (wrong branch, withdrawn)
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42857 Bug ID: 42857 Summary: AddReturn early returns skip transfer processing (wrong branch, withdrawn) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Blocks: 42851 Target Milestone: --- Split off from bug 42851. AddReturn has early-return paths that fire BEFORE the transfer-receive block at C4/Circulation.pm:2553: - "Return not allowed at this branch" (CanBookBeReturned fails) returns at C4/Circulation.pm:2435. - Withdrawn item with BlockReturnOfWithdrawnItems returns at C4/Circulation.pm:2362. If an in-transit item is scanned at such a branch, the transfer is never touched and the row is orphaned on the "Transfers to receive" report. Proposed approach: an item arriving at its transfer destination should override the check-in block. More generally, transfer processing should run (or at least be evaluated) even on these blocked-return paths, so an active transfer is correctly received/resolved before the block is applied. Test plan: 1. Set up a circulation rule / withdrawn-block that blocks return at branch B. 2. Transfer an item to B (in transit). 3. Check it in at B. 4. Before: return blocked, transfer left in transit. 5. After: arrival at the destination is honoured and the transfer is received. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 42859] New: Move transfer-resolution logic from returns.pl down into AddReturn
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42859 Bug ID: 42859 Summary: Move transfer-resolution logic from returns.pl down into AddReturn Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 42852, 42853, 42854, 42855, 42856, 42857, 42858 Blocks: 42851 Target Milestone: --- Split off from bug 42851. Final consolidation step. The logic that resolves a mis-routed transfer on check-in (cancel the stale in-transit row + create a corrected transfer to the original destination, and re-link holds) currently lives only in the staff check-in controller circ/returns.pl:554-578. Every other check-in entry point (SIP2, OPAC self check-in, OPAC self-checkout, inventory tool, automatic check-in) re-calls AddReturn directly and must each re-implement or ignore this handling - which is exactly how items get orphaned in transit (see dependent bugs). Once the per-interface behaviours are agreed on the dependent bugs, move the shared resolution into C4::Circulation::AddReturn (or a helper it calls) so all callers benefit from one DRY implementation, with per-interface presentation (screen messages, prompts, exceptions-bin routing) layered on top via the returned messages hash. This bug deliberately depends on the per-interface bugs so each use case is considered carefully before the logic is unified. Test plan: 1. Verify each dependent bug's agreed behaviour is preserved after the refactor. 2. Confirm AddReturn resolves mis-routed transfers regardless of caller. 3. Run t/db_dependent/Circulation*.t and SIP/transfer tests. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42852 [Bug 42852] SIP2 self-check check-in does not resolve mis-routed transfers https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42853 [Bug 42853] OPAC self check-in does not resolve mis-routed transfers https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42854 [Bug 42854] OPAC self-checkout does not handle items that are in transit https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42855 [Bug 42855] Inventory tool check-in does not resolve mis-routed transfers https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42856 [Bug 42856] Automatic check-in does not resolve open transfers https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42857 [Bug 42857] AddReturn early returns skip transfer processing (wrong branch, withdrawn) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42858 [Bug 42858] AddReturn does not handle Transfer->receive OnLoan exception gracefully -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42858] New: AddReturn does not handle Transfer->receive OnLoan exception gracefully
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42858 Bug ID: 42858 Summary: AddReturn does not handle Transfer->receive OnLoan exception gracefully Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Blocks: 42851 Target Milestone: --- Split off from bug 42851. Koha::Item::Transfer->receive throws Koha::Exceptions::Item::Transfer::OnLoan if the item is still checked out (Koha/Item/Transfer.pm:173). It is called unguarded inside AddReturn (C4/Circulation.pm:2560, 2573). An uncaught exception there aborts the check-in mid-way, potentially leaving the transfer unresolved and the operation in an inconsistent state. Proposed approach: catch the exception, deal with the transfer sensibly, and prompt the staff member for action rather than dying. Test plan: 1. Construct the state where an item has an open transfer and is still shown as checked out at the point receive() is called. 2. Check the item in. 3. Before: exception bubbles up, check-in aborts, transfer unresolved. 4. After: handled gracefully with a clear staff prompt; transfer state consistent. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42856] New: Automatic check-in does not resolve open transfers
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42856 Bug ID: 42856 Summary: Automatic check-in does not resolve open transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Blocks: 42851 Target Milestone: --- Split off from bug 42851. The automatic check-in process (Koha::Checkouts::automatic_checkin, calling C4/Circulation.pm AddReturn at Koha/Checkouts.pm:88) ignores any WrongTransfer message, so an open transfer can be left orphaned. The use case here needs clarification before implementing: automatic check-in operates on overdue checked-out items by itemtype, so an in-transit (not checked out) item is an edge case. One option is a flag/option to mark check-in of items with open transfers as transfer-complete, or to simply skip and report them. Test plan: 1. Configure an itemtype with automatic_checkin. 2. Construct the edge case where an item has an open transfer at run time. 3. Define and verify agreed behaviour. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42855] New: Inventory tool check-in does not resolve mis-routed transfers
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42855 Bug ID: 42855 Summary: Inventory tool check-in does not resolve mis-routed transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 42851 Target Milestone: --- Split off from bug 42851. The inventory tool calls AddReturn($barcode, $item->homebranch) (tools/inventory.pl:269). If an item is in transit to a branch other than its homebranch, AddReturn returns WrongTransfer, which the inventory tool ignores. The original in-transit branchtransfers row is orphaned and shows forever on the "Transfers to receive" report. This case needs more consideration than the self-service interfaces: inventory scanning is a bulk/aside operation and we may not want to silently re-route transfers. Decide whether inventory should resolve the transfer, flag it for staff review, or report it in the inventory results. Test plan: 1. Transfer an item from A to B (in transit). 2. Scan the item's barcode in the inventory tool at branch C. 3. Define and verify agreed behaviour for the open transfer. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42854] New: OPAC self-checkout does not handle items that are in transit
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42854 Bug ID: 42854 Summary: OPAC self-checkout does not handle items that are in transit Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 42851 Target Milestone: --- Split off from bug 42851. opac/sco/sco-main.pl:180 calls AddReturn and only inspects $success; it does not consider that the item may be in transit. The transfer-on-checkout logic in C4/Circulation.pm:1754-1771 force-closes a transfer when an item is issued via the staff client, but the SCO path needs explicit, considered handling. Open questions to resolve on this bug: - Should we BLOCK self-checkout of an item that is in transit? - If we allow the checkout, we must still do something sensible with the transfer, because there is still an expectation the item eventually reaches the original destination branch. Test plan: 1. Transfer an item from A to B (in transit). 2. Attempt to self-check-out the item at branch C via OPAC SCO. 3. Define and verify the agreed behaviour (block, or allow + handle the open transfer). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42853] New: OPAC self check-in does not resolve mis-routed transfers
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42853 Bug ID: 42853 Summary: OPAC self check-in does not resolve mis-routed transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 42851 Target Milestone: --- Split off from bug 42851. When an in-transit item is checked in via the OPAC self check-in (SCI) interface at a branch that is NOT the transfer's tobranch, the WrongTransfer message from AddReturn is ignored entirely (opac/sci/sci-main.pl:81 only reads $success). The original in-transit branchtransfers row is orphaned and shows forever on the "Transfers to receive" report. Proposed approach: - Same transfer resolution as the SIP2 case (bug 42851 child): complete the original transfer recording the actual location, open a new transfer from the check-in branch to the original tobranch, and re-link holds. - Additionally surface a screen message so the patron/staff route the item to the exceptions bin rather than the normal returns shelf. Test plan: 1. Transfer an item from A to B (in transit). 2. Check it in at branch C via OPAC self check-in. 3. Before: branchtransfers row A->B stays open forever, no message. 4. After: transfer resolved + new C->B transfer created, exceptions-bin message shown. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42852] New: SIP2 self-check check-in does not resolve mis-routed transfers
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42852 Bug ID: 42852 Summary: SIP2 self-check check-in does not resolve mis-routed transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 42851 Target Milestone: --- Split off from bug 42851. When an item that is in transit (datesent set) is checked in via the SIP2 self-check interface at a branch that is NOT the transfer's tobranch, AddReturn returns a WrongTransfer message but does not close the row. C4/SIP/ILS/Transaction/Checkin.pm:158-161 only sets destination_loc and an alert; it never cancels/redirects the stale transfer. The original in-transit row is orphaned and shows forever on the "Transfers to receive" report. (The staff page circ/returns.pl:554-578 does handle this; SIP does not.) Proposed approach: - Complete the original transfer, recording the actual branch it ended up at (update tobranch / comment so the error is recorded, not lost). - Open a new transfer from the check-in branch to the original tobranch. - Re-link anything pointing at the old transfer (e.g. holds) to the new one so a subsequent check-in at the correct branch triggers correctly. Test plan: 1. Transfer an item from A to B (in transit). 2. Check it in at branch C via a SIP2 self-check device. 3. Before: branchtransfers row A->B stays open forever. 4. After: original transfer recorded as resolved at C, new transfer C->B created and in transit, holds re-linked. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0