August 2025 - Koha-bugs - lists.koha-community.org

[Bug 35669] New: Update check in message for a specific authorized value in the LOST authorized values
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35669 Bug ID: 35669 Summary: Update check in message for a specific authorized value in the LOST authorized values 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: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Set an item to a Lost status of "Lost". When you check in that item you will get a message that says "Item was lost, now found." 2. Set an item to a Lost status of "Missing". When you check in that item you will get the same message that says "Item was lost, now found." Some libraries would like this message to reflect the correct authorised value that was previously set. So if they have a lost value of "In repair", the check in message would say "Item was In repair, now found." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 29069] New: Accessibility: "Refine your search" link doesn't have sufficient contrast
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29069 Bug ID: 29069 Summary: Accessibility: "Refine your search" link doesn't have sufficient contrast Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bolshawh(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org The "refine your search" link on the OPAC search results page (opac-search.pl) is hard to read (grey text on a grey background) and doesn't meet accessibility guidelines. WCAG 2.1 1.4.3 Contrast (Minimum) Level AA: "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: - Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; - Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. - Logotypes: Text that is part of a logo or brand name has no contrast requirement." (https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#contrast-minimum) There are several free websites for checking the contrast ratio, e.g. https://webaim.org/resources/contrastchecker/ You can also use the built-in accessibility functions in Firefox and Chrome, as well as specialist accessibility browser extensions like WAVE (https://wave.webaim.org/) -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 39809] New: Category name and code in red and italic in patron category form
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39809 Bug ID: 39809 Summary: Category name and code in red and italic in patron category form Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In main, when I go to the patron category form, the required fields' inputs are in red and italic. To recreate: A.1. Go to Administration > Patron categories A.2. Click New category --> Notice the labels for Category code, Description and Category type are in italic (they used to be just red and bold, but not italic) A.3. Type in a code and a description --> Notice that the input is now in red and italic (it used to be black and regular/not italic) B.1. Go to Administration > Patron categories B.2. Click on an existing category --> Notice the description inside the input field is in red and italic (it used to be black and regular/not italic) -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 39960] New: Improve messages in opac-discharge.tt
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39960 Bug ID: 39960 Summary: Improve messages in opac-discharge.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There's a use of 'item(s)' that can be avoided, and the messages contain a redundant 'checked out items' that could just be 'them'. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 37214] New: We should migrate to Koha::Patron->queue_notice wherever possible
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37214 Bug ID: 37214 Summary: We should migrate to Koha::Patron->queue_notice wherever possible Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The 'queue_notice' method introduced to Koha::Patron in bug 15986 introduces a wrapper around GetPreparedLetter and EnqueueLetter that will appropriately pick the message transport type and for the patron based on their own preference and personal data provided. We should try to use this method consistently throughout Koha rather than manually setting these in different area's of the codebase. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 37050] New: Add select2 to SQL report multi select
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37050 Bug ID: 37050 Summary: Add select2 to SQL report multi select Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org Bug 36545 adds select2 to improve the user experience when making multiple selections in item search. Bug 35746 adds the ability to reports to make multiple selections for SQL parameters. It would be nice for consistency and ux for the report multiselect to use select2. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62

[Bug 40235] New: You cannot see the holds affecting borrower's checkouts, if the borrower has restrictions
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40235 Bug ID: 40235 Summary: You cannot see the holds affecting borrower's checkouts, if the borrower has restrictions Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If the borrower has restrictions on their account, you cannot see the holds that affect borrower's checkouts. Usually you see from the staff interface, if there are any holds towards borrower's checkouts, and they prevent renewals. However, if a borrower has some restrictions, you cannot see the holds. Koha only shows that renewal is impossible because of the restriction. Affecting holds would be important information, when you discuss with the borrower about their situation and what they have to do to lift the restrictions. To demonstrate the problem: 1. Create borrowers A and B 2. Check out some items (i,j) to borrower A. 3. Place a hold for the item i by borrower B. 4. See from check-outs of borrower A, that you can see that the item i cannot be renewed, since there's a hold for that item. The item j is possible to renew. 5. Create a restriction for the borrower A. 6. See the check-outs of borrower A, and notice that all the checkouts seem the same. none of them are seen as renewable. Further, you can try to "override renewal restrictions". Then you can see that all the checked-out items now have a checkbox for renewal. If you actually do try to renew those, the one on hold says "Renew failed: on hold". So that actually works as it should, but you just don't see the situation beforehand. In cases of restrictions, it would be good to be able to tell the borrower about the possible holds. Otherwise you might have a situation, where borrower comes again, settles the cause that was the reason for the restriction, restriction is remowed, and only after that the borrower (and staff) finds out that all the check-outs cannot be actually renewed, because of the holds. So I propose that even in cases of borrower having restrictions, the holds that affect their checkouts would be visible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 37230] New: Add ability to define arbitrary statuses for items in Z3950
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37230 Bug ID: 37230 Summary: Add ability to define arbitrary statuses for items in Z3950 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 36996 adds the ability to define a not-available status for items in Z3950 based on several criteria It would be nice to extend the use of YAML here to allow for defining several different statuses for different criteria -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36996] New: Add a system preference to determine Z3950 availability
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36996 Bug ID: 36996 Summary: Add a system preference to determine Z3950 availability Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries would like to use additional item fields for determining if an item is available when showing z3950 results. This bug is to add a new system preference to determine availability (yes|no) via a YAML system preference - similar to OPacHiddenItems -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 29509] New: GET /patrons* routes permissions excessive
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29509 Bug ID: 29509 Summary: GET /patrons* routes permissions excessive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com The routes require full borrowers permissions, and that's not the case for Koha, generally. If required permissions were to be lowered, bug 29503 should be pushed first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71