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

[Bug 40364] New: Add permission for viewing patron holds history
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40364 Bug ID: 40364 Summary: Add permission for viewing patron holds history 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 32682 Bug 32682 is adding a permission for the ability to view patron checkout history. We also need a parallel permission for patron holds history. We should make it so when IntranetReadingHistoryHolds is enabled, users with this new permission can see patron hold history but users without the permission cannot. When IntranetReadingHistoryHolds is disabled, no users should be able to see patron hold history. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32682 [Bug 32682] Add permission for viewing patron reading history -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 42062] New: Patron column missing from checkout history on biblio record
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42062 Bug ID: 42062 Summary: Patron column missing from checkout history on biblio record 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 32682 The Patron column on the checkout history tab of a bib (/cgi-bin/koha/catalogue/issuehistory.pl) isn't showing up properly due to a typo in a permission check in the template file. It should be checking "CAN_user_circulate_circulate_remaining_permissions" but instead has "CAN_user_circulate_remaining_permissions" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32682 [Bug 32682] Add permission for viewing patron reading history -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 32682] New: Add permission for viewing patron reading history
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32682 Bug ID: 32682 Summary: Add permission for viewing patron reading history Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With intranetreadinghistory it is an all or nothing option - there are often situations where staff will need to view this, but not necessarily every staff member needs to see the information. It would be great to add the ability to view this to the permissions so libraries can decided which staff have this ability. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 22212] New: Improve usability of column configuration page
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22212 Bug ID: 22212 Summary: Improve usability of column configuration page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Target Milestone: --- The column configuration page currently doesn't translate well. The modules on the tabs translate, but neither do the id= parts or the columns. I think as a first step it would help to navigate these pages if we could add a little description on where the table appears somewhere that is translatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

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

[Bug 41795] New: UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41795 Bug ID: 41795 Summary: UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org As per the Bug Summary, when you search for Corporate Body Name authorities (authtypecode 'CO') in the OPAC or in the Staff interface, the results will also include Collective Titles (authtypecode 'CO_UNI_TI'). The problem manifests in UNIMARC instances that use the default authority type codes and a Zebra search backend. AIUI, it has to do with 'Corporate Body Name' authorities using an authtypecode ('CO') that just so happens to be the prefix of another authtypecode ('CO_UNI_TI') used by 'Collective Title' authorities. Out of the box, MARC21 instances aren't affected by this. However, in the (unlikely?) scenario that you've decided to catalog authorities under different authtypes than the built-in ones and somehow managed to add new authority types that share the same prefix ('AUTH', 'AUTH_CORP', 'AUTH_PERS', etc.), then you will run into problems when searching as there will be no guarantee that filtering for the specific authority type 'AUTH' will return only the results you will be expecting. Elasticsearch is not affected -- it's a Zebra-only thing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33