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

[Bug 41409] New: Streetnumber has a different data type in borrower_modifications
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41409 Bug ID: 41409 Summary: Streetnumber has a different data type in borrower_modifications Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org The streetnumber field is inconsistent between the borrowers and borrower_modifications table - tinytext and varchar(10) respectively -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 41411] New: Streetnumber field is limited to 10 characters despite being tinytext
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41411 Bug ID: 41411 Summary: Streetnumber field is limited to 10 characters despite being tinytext 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: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The streetnumber input fields are limited to 10 characters which can be difficult for using house names instead of house numbers -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 35451] New: Add tablename field to additional_field_values
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35451 Bug ID: 35451 Summary: Add tablename field to additional_field_values 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 Currently we rely on a subquery in the additional_field_values relationships we're adding in various places. For performance and code clarity it would be sensible to add a tablename field to the additional_field_values table to denote which table the value is pertaining to.. we could index this too. This would allow us to drop the subquery and use an indexed field instead during joins. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 116

[Bug 32541] New: Masthead search bar cut off in Chrome on mobile or in narrow window
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32541 Bug ID: 32541 Summary: Masthead search bar cut off in Chrome on mobile or in narrow window Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 144870 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=144870&action=e… mobile error When viewing the staff interface in Chrome on mobile or in a very narrow window, the main search bar doesn't properly scale down to the smaller size and gets cut off. I've attached a screenshot. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28071] New: Ability to batch remove titles from a list
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28071 Bug ID: 28071 Summary: Ability to batch remove titles from a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Sometimes, lists can have a quite large number of titles. With the export option, it's easy to work on this corpus, and, sometimes, find some titles we finally don't want in that list. If they are numerous, it's for now quite painful to find and delete them. A useful option could be, as it exists with the button "Add items", to be able to remove several titles at a time using barcode or biblionumber. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33037] New: [Bugs 32555 and 31313 follow-up] Koha does not display difference between enumchron and serialseq in record detail view (OPAC and intranet)
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33037 Bug ID: 33037 Summary: [Bugs 32555 and 31313 follow-up] Koha does not display difference between enumchron and serialseq in record detail view (OPAC and intranet) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, katrin.fischer(a)bsz-bw.de, tomascohen(a)gmail.com Patch 32555 tries to resolve the issue caused by bug 31313. But the way it is fixed seems to be at least problematic. With patch 32555 we will never see the difference between `serial`.`serialseq` and `items`.`enumchron` which is still intended in opac-detail.tt (line ~ 1332) and [intranet] catalogue/detail.tt (line ~ 446). This is because ITEM_RESULT.serialitem (in opac-detail.tt) and item.itemserial.serial (in catalogue/detail.tt) refer to non-existing things. (and therefor the problem described in 32555 no longer emerge). The original problem is caused by mixing up serialitem with serial in [opac-]detail.pl and passing serialitem instead of serial to both templates. A patch will follow. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 33254] New: 2FA - Trust Current Device
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33254 Bug ID: 33254 Summary: 2FA - Trust Current Device Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.sam(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 20476 I've been testing the 2FA Koha module, I noticed there's currently no option to "trust current device" something that most MFA modules include, so a user can mark a local device to be excluded from the MFA check for an amount of time (typically a month or so). Not very essential, but would be a nice quality of life feature for users with dedicated machines. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20476 [Bug 20476] Two factor authentication for the staff client - omnibus -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 28680] New: Staff without edit_borrower permission still see patron information
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28680 Bug ID: 28680 Summary: Staff without edit_borrower permission still see patron information Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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 The permission edit_borrowers specifies: Add, modify and view patron information. However, when that permission is not enabled, staff can view patron information in a number of places, including holds queue, circulation.pl, waitingreserves.pl, and pendingreserves.pl. In the Holds Queue staff can see patron name and other info for patrons at their library, but patrons from other libraries show "patron from central branch" etc. When looking at a bib record, if an item is checked out, only the borrower number is displayed. This should be consistent, where staff without that permission only see a borrower number and nothing else. To replicate, create a staff member with only permissions catalogue ( to log in) and circulate_remaining_permissions. Check out to a patron, see the holds queue, etc and see that the patron information is displayed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 37144] New: Add a subpermission for hiding patron contact information
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37144 Bug ID: 37144 Summary: Add a subpermission for hiding patron contact information Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Patrons Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, Koha lacks a subpermission feature that allows libraries, especially those in correctional facilities utilizing inmate volunteers, to hide patron contact information (e.g., addresses) from certain users like volunteers. This privacy gap poses a significant risk, potentially exposing sensitive inmate data to unauthorized personnel. Implementing a subpermission feature would ensure that only authorized staff can access such sensitive information, addressing critical privacy concerns within these specialized library environments. -- You are receiving this mail because: You are watching all bug changes.

1 62

[Bug 39054] New: a need to distinguish between manual bibliographic record modifications and those being a consequence of authority modification
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39054 Bug ID: 39054 Summary: a need to distinguish between manual bibliographic record modifications and those being a consequence of authority modification Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Now in action_logs, Koha does not distinguish between manual bibliographic record modifications and those being a consequence of authority modification. Both are logged in the same way: module: CATALOGUING ; operation: MODIFY ; interface: intranet. IMO it would be helpful to be able to distinguish this two cases. (For instance to be able to evaluate a librarian's 'koha' in the cataloguing process: a single action of modification of one authority record launching a modification of, say, 100 bibliographic records does not equal to manual modification of 100 bibliographic records. Also, if we trace issues in bibliographic records after modification being performed and want librarians to correct themselves, a biblio modification being a consequence of an authority modification should not be taken into account. Etc.) Comment are welcome. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28