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

[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

[Bug 35645] New: Modification Log only show changed values
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35645 Bug ID: 35645 Summary: Modification Log only show changed values Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: angela.berrett(a)familysearch.org QA Contact: testopia(a)bugs.koha-community.org CC: angela.berrett(a)familysearch.org, gmcharlt(a)gmail.com Created attachment 160266 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160266&action=e… OLIB cataloging system item modification log The modification logs for a bib record puts all bibliographic and item information in a single text box when an edit occurs. For easier reading it would be nice to only show the fields/information that were modified. A previous catalog our library used would show a single line per change when an item was modified. It would show the date | person who made the change | old value | new value. This kept an accurate history and made reviewing the changes easy to read. As there is a single modification page for all items on a bib record the object column identifying which item was changed would need to be included. A similar table could be created for bib record modifications identifying the MARC field that was changed either in the Object column or in its own column, along with the old and new values. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 41200] New: Refocus certain elements on hide or remove
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41200 Bug ID: 41200 Summary: Refocus certain elements on hide or remove Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org On the OPAC, there are a few instances of the browser's focus caret disappearing when an element is removed. This causes problems for people with screen readers, as their reader doesn't know what element should come next in the page's flow any more. I shall propose a set of patches to resolve this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 39328] New: Buttons should maintain focus after toggling
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39328 Bug ID: 39328 Summary: Buttons should maintain focus after toggling Change sponsored?: --- Product: Koha Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, oleonard(a)myacpl.org A customer's accessibility report has highlighted to us a malfunction on some of our button focus behaviours. To paraphrase the auditor: "When it is activated on highlight / unhighlight, the focus moves to a random location on the page, such as to the "1" pagination button. That is, as opposed to staying on the activated link. Witnessed on iOS. Also witnessed on OPAC details, via iOS, with the "Add to cart" link. When activated, the focus moves to a random location on the page, such as to the decorative folder icon preceding the link's label. That is, as opposed to staying on the activated link, which now has an updated label of "In your cart". Again on iOS, with the "highlight/unhighlight" links on OPAC details. When activated, the focus moves to a random location on the page, such as to the "Print" link. That is, as opposed to staying on the activated button. Additionally, with the sortable header column buttons, on search history, on iOS. When activated, the focus moves to a random location on the page, such as to the "Enter search here" input field. That is, as opposed to staying on the activated button. Lastly, on iOS, on the OPAC details page, with the "+/-" buttons in the holdings table. When activated, the focus moves to a random location on the page, such as to the first table header. That is, as opposed to staying on the activated button." I'm not sure how much of these issues can be attributed to us, versus iOS/Safari just being... iOS/Safari. I thought I would log here, anyway. :-) Jake. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 23350] New: Add another variable for advanced prediction pattern
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23350 Bug ID: 23350 Summary: Add another variable for advanced prediction pattern Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Hi, Currently, in the prediction pattern we can only set 3 variables (X, Y, Z). For long numbering such as "Vol., Number, Season, Year" a 4th variable would be useful. Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 41136] New: Advanced doesn't search on SRU servers
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41136 Bug ID: 41136 Summary: Advanced doesn't search on SRU servers Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The advanced editor has a hardcoded use of 'zed' for the type of server, which implies Z39.50 and not SRU. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 42170] New: Librarian-Controlled AI Crawler and Search Traffic Management for OPAC Search Page
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42170 Bug ID: 42170 Summary: Librarian-Controlled AI Crawler and Search Traffic Management for OPAC Search Page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: vimalibre(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I would like to propose a feature for Koha to help libraries manage excessive automated traffic, especially on the OPAC search endpoint such as: opac.yourdomain.com/cgi-bin/koha/opac-search.pl In some cases, this page is being heavily accessed by AI crawlers and other automated agents, which can consume significant server resources and affect normal library service performance. At present, libraries may control this only through external tools such as Cloudflare, Fail2ban, firewall rules, or reverse proxy configurations. However, these approaches often require dedicated IT support, which many libraries may not have. It would be very helpful if Koha could provide built-in tools, configurable from the librarian/staff interface, to allow libraries to manage this traffic based on their own capacity and policy. Requested Functional Requirements: Enable/Disable AI crawler access to OPAC search page Provide an option in the staff interface to allow or disallow AI crawlers from accessing the OPAC search page. This should be manageable by authorized library administrators without requiring server-level intervention. Allow selected crawlers only Provide a configurable allowlist option so that the library may permit only selected crawlers or bots while blocking others. This would help libraries that want discovery/indexing benefits from specific services without opening access to all automated agents. Rate limiting for OPAC search endpoint Provide an option to enable configurable rate limiting specifically for high-hit pages such as opac-search.pl. This may help reduce server load caused by repeated automated queries. Challenge or verification for suspicious/concurrent hits Provide an option to trigger a challenge or verification step when unusually high concurrent requests are detected from the same IP or user agent. This may help distinguish genuine users from abusive automated access. Traffic monitoring and analytics Provide a simple monitoring dashboard or reporting tool within Koha to show: hit counts to the OPAC search page, top requesting IPs, top user agents, frequency trends, possible abusive patterns. This would help librarians or library administrators understand how the page is being used and identify resource-heavy access. View hit count by IP Provide an interface to view the number of requests coming from a specific IP address over a defined period. This would support easier investigation of suspicious traffic. Optional blocklist integration Provide an option for authorized administrators to add suspicious IPs to a Koha-managed deny list. Where feasible, Koha could also support optional mapping/export of such IPs for OS firewall or reverse proxy blocking. Optional Cloudflare/API-based rule integration For libraries already using Cloudflare or similar services, an optional integration could be provided where administrators enter API credentials and enable predefined protection rules from within Koha. This could simplify deployment of recommended protections without requiring advanced IT intervention. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 32751] New: [Omnibus] Extend, improve and standardize additional fields
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 Bug ID: 32751 Summary: [Omnibus] Extend, improve and standardize additional fields 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 Depends on: 11844, 32749, 32750 Additional fields are a great idea, which is why they have spread into several areas of Koha now allowing libraries some flexibility for storing additional data. It would be nice if the functionality could be extend, getting closer to we can already do with patron attributes, but also being more standardized between different types of additional fields. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11844 [Bug 11844] Additional fields for order lines https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32749 [Bug 32749] Additional fields: Make searchable and display in result list separate attributes https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32750 [Bug 32750] Additional fields: Allow fields to be marked as mandatory -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 26258] New: Circulation tabs inconsistent with counters
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26258 Bug ID: 26258 Summary: Circulation tabs inconsistent with counters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The circulation tabs on circulation.pl and moremember.pl are inconsistent between each other and the two pages. Clubs should have counters in front of the name like the other tabs. Restrictions does not have a counter on the circulation.pl page, but it does on the moremember.pl page. Restrictions should be Restriction(s) on both pages. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 16131] New: Messages for branch transfers show with bullet points
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16131 Bug ID: 16131 Summary: Messages for branch transfers show with bullet points Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The branch transfer messages are styled as a list and show with bullet points. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26