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

[Bug 27603] New: Add API for lists management
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27603 Bug ID: 27603 Summary: Add API for lists management Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org Created attachment 116256 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=116256&action=e… Screenshot of the list modal idea I was playing around with making the list add form a modal instead of a popup, and while it can be hacked together as things are now it really would be better to have an API to work with. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 38050] New: Add REST endpoints for working with "lists"/"virtual shelves"
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38050 Bug ID: 38050 Summary: Add REST endpoints for working with "lists"/"virtual shelves" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We don't yet expose the lists functionality over API's, this would be a beneficial enhancement both for internal use and thrid party integrations wishing to integrate with this functionality. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 40092] New: Adding authorities - clicking save doesn't fill auto-populated fields
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '26

31 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40092 Bug ID: 40092 Summary: Adding authorities - clicking save doesn't fill auto-populated fields Change sponsored?: --- Product: Koha Version: Main 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org When adding a new authority record, clicking save (without filling in any fields) doesn't fill in the auto-populated fields such as 000, 003, and 008. In a 24.11.x instance, this works (start up a local instance or use one of the demos): 1. Authorities > New authority > Topical term 2. Don't enter any information in any fields. 3. Click 'save'. 4. Note that fields such as 000 and 003 are auto-populated (not sure if that is the right term). In 25.05.00 or main, this no longer works: 1. Repeat steps 1 to 3. 2. Note that: - fields such as 000 and 003 are not auto-populated - the mandatory fields are now highlighted in yellow - clicking the individual fields doesn't auto-populate them -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 35870] New: Adding an edit_authorities subpermission for editauthorities
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '26

31 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35870 Bug ID: 35870 Summary: Adding an edit_authorities subpermission for editauthorities 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: wainuiwitikapark(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 35914] New: Add permission for changing a user password
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '26

31 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35914 Bug ID: 35914 Summary: Add permission for changing a user password Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement 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 There are situations where libraries do not want staff to be able to change a patron's password using the Change Password button but there is currently no way to split out permission to block this. You have to turn off the ability to view/edit all patron info which is also not helpful. Some libraries prefer that staff either send a password reset email, or direct patrons to the OPAC to reset a password. It would be a great enhancement to add a subpermission to BORROWERS to allow/disallow the ability for staff to change a patron password. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32122] New: Wrong permissions check on item circulation alerts
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '26

31 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32122 Bug ID: 32122 Summary: Wrong permissions check on item circulation alerts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 14391 added granular permissions for the administration module, however, there was a mismatch in the check on item circulation alerts and the new permission -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 21173] New: Run auto item modifications by age every hour and set the item age unit to hours
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '26

29 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21173 Bug ID: 21173 Summary: Run auto item modifications by age every hour and set the item age unit to hours Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Make auto item modification by age cronjob run more often than once daily. Setting this cronjob to run every hour will be set in the /etc/cron.hourly/koha-common. However 2 further changes to the automatic item modification tool to make an hourly running cronjob useful. 1. Be able to set the age of the item in hours not just days. This is so an hourly cronjob has items to alter because items will exceed the age limit more frequently than if the item age is in hours. 2. Give the user the choice of what the age starting point (time from which the age of the item is calculated) used in the cronjob is. The two possible age starting points that users have to choose between are: * Item creation (this is the age starting point in master currently) * Item last altered This is so items whic have been in the catalogue for a while can still be affected by the automatic item modification by age cronjob. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 86

[Bug 42372] New: Allow plugins to add record display customizations
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '26

29 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42372 Bug ID: 42372 Summary: Allow plugins to add record display customizations Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org Following up on the feature introduced in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39860, it'd be nice if plugins could add their own record display customisations as well. Patch coming in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42318] New: Table record_sources is not populated with data on install
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42318 Bug ID: 42318 Summary: Table record_sources is not populated with data on install Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com In bug 35380 the table record_sources gets populated with system defined values as 'bulkmarcimport','intranet' and so on. As this works in updates via a script in db_revs (251200037.pl) these values are not populated on a new installation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 41850] New: Allow to choose message type for CheckPrevCheckout
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41850 Bug ID: 41850 Summary: Allow to choose message type for CheckPrevCheckout Initiative type: --- Sponsorship --- status: 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Currently, if the staff member doesn't have the force_checkout permission, the CheckPrevCheckout parameter is enabled, and the patron already checked out the title in the past, the checkout is blocked and the staff member cannot proceed. It would be great if libraries could choose if CheckPrevCheckout is a blocking warning or a simple message. I've had this comment from a library where the librarian doesn't want the circulation staff to be able to override checkouts to patrons with unpaid fines over noissuescharge for example, but still wants them to be able to check out previously checked out items. I was thinking maybe a system preference to choose the type of message (warning = yellow with confirmation button; or message = blue without confirmation). I'm not sure if most libraries use CheckPrevCheckout as a blocking mechanism for checkouts like noissuescharge or age restriction that actually need a confirmation, or rather a more informative message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1