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

[Bug 30888] New: Add a table for deletedauthorities
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30888 Bug ID: 30888 Summary: Add a table for deletedauthorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Just like deletedbiblio and deleteditems, etc. While the long discussion about merging such tables continues, we should imo add a separate table here for consistency. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 107

[Bug 33552] New: Automatic renewals should only send emails for successes
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33552 Bug ID: 33552 Summary: Automatic renewals should only send emails for successes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I get frequent complaints from libraries about patrons getting emails saying their items can't auto renew. The typical error message is "too_many", and it's sent every single day. Most of the time, we probably only want to send email notices out when the item has successfully renewed. Then notices like advanced item due, item due, and overdues take over from there. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[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 26129] New: Add a new 'configurations' table
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 Bug ID: 26129 Summary: Add a new 'configurations' table 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This table should be designed from the beginning to allow global and per-library configuration entries. It would replicate the circulation_rules schema, but adapted to be a(n eventual) replacement for system preferences. This came up on my development for an SMTP configuration page, in which I originally added an smtp_servers page, that could really be generalized like this for other uses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 86

[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