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

[Bug 31457] New: Move Koha::Patron::Debarment into Koha::Object based classes
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31457 Bug ID: 31457 Summary: Move Koha::Patron::Debarment into Koha::Object based classes Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Collector bug for removing the Koha::Patron::Debarment which is written in C4 style and replacing it with the new Koha::Object based class pair, Koha::Patron::Restriction(s). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 39658] New: Allow definition of non-hierarchical linked patron accounts
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39658 Bug ID: 39658 Summary: Allow definition of non-hierarchical linked patron accounts Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In a Koha system containing multiple functionally-autonomous libraries, one patron may have multiple distinct accounts within the same Koha system. These accounts represent distinct cards from distinct libraries and need their circulation rules enforced as such, so they can't be merged into one account. But no one of these accounts is "primary" and they all represent the same person, so guarantor/guarantee relationships are a poor conceptual fit (and may already be in use for their intended purpose). These linked/shared accounts would: - clearly link between each other in the Details of the patron record - optionally reciprocally enforce restrictions and blocks due to fines & fees (when one account is blocked, all are) - optionally allow checkout of on-hold items for shared accounts For that last item, assuming one patron has accounts card1 and card2. They have a hold ready for pickup on their card1 account. If Koha attempts to check the waiting item out to the card2 account, koha should check the item out on the card1 account, mark the hold complete, and give the user a clear on-screen message as to what happened. It should not ask for confirmation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 167

[Bug 42503] New: Optimize retrieval and display of the holds queue
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42503 Bug ID: 42503 Summary: Optimize retrieval and display of the holds queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com The holds queue page (view_holdsqueue.pl) should be reworked to fetch data via API to improve performance for large systems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 134

[Bug 32419] New: Show availability in list view in staff interface
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32419 Bug ID: 32419 Summary: Show availability in list view in staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When viewing a list on the OPAC, you can see the item's availability. But in the staff interface, this information is not visible. To test : 1. In the staff interface, add an item to a list 2. View the list --> No availability is visible 3. Go to the OPAC and view the list --> You can see the availability of the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 21453] New: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 Bug ID: 21453 Summary: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: arouss1980(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you add or alter an authority record and edit one of the MARC fields in UNIMARC 5XX 'See Also Reference Tracing Block' [1], you can click on the ellipsis (...) next to a subfield [2] to launch the authority finder plugin. This plugin allows you to search for an authority and then pick an entry from the 'Special relationship:' dropdown menu in order to set the relationship between the two authorities. The results list of the authority finder contains 'Choose' buttons which _should_ insert all data from the chosen authority into the appropriate subfields of the MARC tag you are editing [3]. However, in UNIMARC setups this does not work: clicking on 'Choose' only populates subfield $a ('Entry Element') with data, but not subfields $3 and $5 ('Authority Record Number' and 'Tracing Control', respectively), which are just as important for correct authority linking. I've tracked this down to these lines of code which are MARC21-specific and use hardcoded subfield values in blinddetail-biblio-search.pl: 91 for ( $field->subfields ) { 92 next if $_->[0] eq '9'; # $9 will be set with authid value 101 push( @subfield_loop, { marc_subfield => 'w', marc_values => $relationship } ) if ( $relationship ); There is also this code in the template blinddetail-biblio-search.tt: 38 [%- END -%]‡9[% authid | html %]"; 138 if(code.value=='9'){ 139 subfield.value = "[% authid |replace("'", "\'") |replace('"', '\"') |replace('\n', '\\n') |replace('\r', '\\r') %]"; These code fragments don't work 100% because in UNIMARC authorities the authid value is stored in subfield $3 and the relationship code in $5. I propose to modify the Perl script above (which is currently MARC flavour agnostic), have it check the 'marcflavour' system preference, and use that to decide which subfield to push the authority relator code to. A similar approach in the template file will set the authid subfield value depending on whether you are a MARC21 or UNIMARC user. [1] Known as the 'Related Access Point Block' in recent IFLA updates. [2] For the ellipsis to appear next to a subfield, you must view the MARC structure of the relevant authority type and then edit the subfields of the tag you're interested in. Finally, you must select an authority type from the 'Thesaurus:' dropdown menu. [3] Under the hood each 'Choose' button is a call to the JS function doauth(), which in turn calls blinddetail-biblio-search.pl with the parameters required (authid, relationship, etc.). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 42161] New: Non-mandatory patron attribute type does not appear in members-update.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42161 Bug ID: 42161 Summary: Non-mandatory patron attribute type does not appear in members-update.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Modifying a non-mandatory patron attribute type in the OPAC is not taken into account in the Update patron records page in the staff interface, when the field was blank at the point of self-registration and has never been updated in the staff interface. To replicate: 1. Create a mandatory patron attribute type: go to Administration > Patron attribute types > New. For example, give it code NEWS and description 'Receive newsletter?' Tick: Display in OPAC, Editable in OPAC, OPAC mandatory. 2. Create a non-mandatory patron attribute type: go to Administration > Patron attribute types > New. For example, give it code SUPREQ and description 'Support requirements'. Tick: Display in OPAC, Editable in OPAC. 3. Set up self-registration: set the PatronSelfRegistration system preference to 'Allow'. 4. Make sure PatronSelfRegistrationDefaultCategory is filled with a patron category. 5. Set the OPACPatronDetails system preference to 'Allow'. 6. Go to the OPAC > Create an account (opac-memberentry.pl) and add some details. Under Additional information, enter a value for 'Receive newsletter?' but leave 'Support requirements' blank. Submit. 7. Login to the OPAC with your newly-registered patron. 8. In the personal details tab, add a value solely for 'Support requirements'. Submit update request. 9. From the staff interface homepage, click Patrons requesting modifications (members-update.pl). 10. A request for the patron created in step 6 appears, with a section entitled Additional attributes and identifiers. There is one row Field = Newsletter; old value and new value are the same. Note that we did not update Newsletter in step 8; this row should not appear. Note that we added a value for Support requirements in step 8: this does not appear; this is the bug being reported. 11. Approve the update request: tick Approve then click Submit. 12. In the staff interface, go to the patron acccount. Note that the Support requirements field is still empty. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 42385] New: Extract _GetCircControlBranch into Koha::Policy::Circulation
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 Bug ID: 42385 Summary: Extract _GetCircControlBranch into Koha::Policy::Circulation 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: 41728 _GetCircControlBranch is a private function in C4::Circulation that is exported (the code itself comments "This is wrong!") and used from Koha::Item, Koha::Recall, and multiple places in C4::Circulation. It resolves which library controls circulation rules given the CircControl and HomeOrHoldingBranch system preferences. This is the exact same pattern as Koha::Policy::Holds->holds_control_library, which resolves the controlling library for hold rules based on ReservesControlBranch. This bug proposes: - Add Koha::Policy::Circulation with a circ_control_library($item, $patron) class method - Replace all _GetCircControlBranch calls with the new method - Remove the exported private function from C4::Circulation - Add unit tests This is a prerequisite for the checkout availability work, as the future Koha::Item::Checkout::Availability class would need to resolve the controlling library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 42386] New: Unify hold availability checks into Koha::Availability pattern
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42386 Bug ID: 42386 Summary: Unify hold availability checks into Koha::Availability pattern 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: 41728, 42385 Hold availability is currently split across three different interfaces with different return shapes: - Koha::Patron->can_place_holds â patron eligibility gate Returns Koha::Result::Boolean with messages - C4::Reserves::CanItemBeReserved â item-level hold policy Returns hashref with {status} - C4::Reserves::CanBookBeReserved â biblio-level hold policy Returns hashref with {status} This bug proposes unifying these into the Koha::Availability pattern introduced in bug 41728: - Koha::Patron::Hold::Availability â patron eligibility checks (expired, debt, restricted, card lost, global hold limit) - Koha::Item::Hold::Availability â item-level hold policy checks (hold policy, circ rules, on-shelf holds, pickup location, etc.) Both would return Koha::Availability::Result and support no_short_circuit and overrides, consistent with the checkin availability class. This would also require untangling patron-level checks that leaked into CanItemBeReserved (e.g. maxreserves in certain code paths) and pushing them back to the patron-level orchestrator. Note: This is a significant refactoring effort. CanItemBeReserved has ~15 different checks with complex interactions. A multi-patch approach is recommended. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 [Bug 42385] Extract _GetCircControlBranch into Koha::Policy::Circulation -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 107

[Bug 42475] New: Terminology: OPAC is an abbreviation
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42475 Bug ID: 42475 Summary: Terminology: OPAC is an abbreviation Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating and requires another look/confirmation in the GUI still: Sytem preference: NovelistSelectProfile on the opac de-DE-pref.po, 1485 -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 41419] New: Error javascript "undefined" is not valid JSON when showing the order edit modal in orderreceive.tt
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41419 Bug ID: 41419 Summary: Error javascript "undefined" is not valid JSON when showing the order edit modal in orderreceive.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org to reproduce 1. Go to Acquisitions → New vendor, enter a name, check Vendor is Active, and click Save. 2. Click the name of the vendor you just created in the table. 3. Click New → Basket, enter a basket name, and click Save. 4. Click Add to basket → From a new (empty) record. Enter a title, add an item, and click Save. 5. Click Close basket. 6. Click Receive shipments, enter a number in the Vendor invoice field, and click Next. 7. Click Receive for the created line. 8. Open the browser console. 9. In the modal, tick the Receive? checkbox and click Confirm. 10. Go to the previous page → The console shows the error: "undefined" is not valid JSON at JSON.parse (<anonymous>) was shown 11. Apply the patch 12. Go to Acquisitions → Search for the vandor created on step 2 13. Repeat step 3, 4, 5, 6, 7, 8, 9, 10 → There is no js error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17