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

[Bug 42848] New: CSS checker rules needs update
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42848 Bug ID: 42848 Summary: CSS checker rules needs update Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Target Milestone: --- When I have the following in CSS: #opac-patron-registration :is(#header-region, #breadcrumbs, #google_translate_element) { display: none; } It throws the following warning (Red X bang) next to the line: Expected RPAREN at line 1, col 31. And it underlines the hashtag for #header-region. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 41381] New: Suppress CodeMirror warnings for CSS
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41381 Bug ID: 41381 Summary: Suppress CodeMirror warnings for CSS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In CodeMirror, a warning is shown if you use more modern CSS. For example: li:has(#checkprevcheckout) { display: none; } This is valid, but CodeMirror displays a warning. Same for nested CSS: .thing1 { .thing2 { display: none; } } Also valid, but it recreates warnings that would make you think otherwise. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 31059] New: encryption_key config entry not generated when upgrading
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Bug ID: 31059 Summary: encryption_key config entry not generated when upgrading Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It's required for 2FA (from bug 28786) but it's not added to koha-conf.xml when upgrading. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 39592] New: requestspecific table on reserve/request.pl should be column configurable
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39592 Bug ID: 39592 Summary: requestspecific table on reserve/request.pl should be column configurable Change sponsored?: --- 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some would find it handy if they could configure which columns appear, and choose a default sort order, of the requestspecific table on reserve/request.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[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 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