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

[Bug 39471] New: WCAG 2.4:2.4.4 - Link Purpose (In Context)
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39471 Bug ID: 39471 Summary: WCAG 2.4:2.4.4 - Link Purpose (In Context) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(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 Across Koha's OAPC, links and buttons are generally very clear and contain suitable aria-label text. However, on the ‘Details for’ pages, there are repeated ‘Browse shelf’ links that require additional context to be clear. Solution: Ensure that the meaning of all links and buttons is clear without relying on surrounding content: • For text links, hyperlink the descriptive part of the sentence. Keep link text short and succinct so it can easily be identified and understood by screen reader users • For buttons, add an aria label or aria-labelledby attribute to provide the relevant context -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 29492] SPAM
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29492 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- *** Bug 39471 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acampbell(a)buttecounty.net --- Comment #24 from Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.net> --- Looks like it's been a while since the last update, but this would be very helpful for us, too. Staff don't need a short timeout, but the public do -- I don't have a way to count how many patrons placed holds on someone else's account because they weren't signed out, but I know it's happened. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39893] New: Show and make searchable translated and transliterated titles in OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39893 Bug ID: 39893 Summary: Show and make searchable translated and transliterated titles in OPAC Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: angela.berrett(a)familysearch.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 182392 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182392&action=e… Example of translated (242$a) and transliterated (246$a) titles We have a lot of international books in many languages even though we are an English-based library. We often create translated titles (242$a) and other varying titles (246$a) for these books. Sometimes we use the 246$a for the spine title if it differs from the main title, or if the publisher/author provided a translated/parallel title, or if we create a transliterated title. However, these titles do not appear in the OPAC (Aspen), nor are they searchable by these titles. We would like to see these titles to appear in the OPAC. If possible, make them searchable as well. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 35892] New: Fallback to GetMarcPrice in addorderiso2907 no longer works
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35892 Bug ID: 35892 Summary: Fallback to GetMarcPrice in addorderiso2907 no longer works Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 34169 broke a fall back to the GetMarcPrice routine when ordering from a file. Previously if there was no order, the field was blank and evaluated as 'false' and we used the price from the MARC record. Now the field is '0.00' if no price is mapped in MarcFieldsToOrder. perl -e 'warn "True" if "0.00"'; IN addorderiso2907.pl: my $c_price = $input->param( 'price_' . $import_record->import_record_id ) || GetMarcPrice( $marcrecord, C4::Context->preference('marcflavour') ); We could simply add 0 to tthe value to make it a number: perl -e 'warn "True" if "0.00"+ 0'; However, this would mean leaving the field at 0.00 when you didn't pay for something would change it to the GetMarcPrice. I think the solution may be to populate the field using the GetMarcPrice on the initial load. You can workaround this by adding the fallback to the MarcFieldsToOrder system preference: price: 947$c|020$c Which may be a viable solution for updating/editing the default values/documentatoin for that preference -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 35871] New: Adding a merge_delete_authorities subpermission for editauthorities
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35871 Bug ID: 35871 Summary: Adding a merge_delete_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 watching all bug changes. You are the assignee for the bug.

1 20

[Bug 38007] New: Records created through Acquisitions with Acquisitions framework are saved in Default
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38007 Bug ID: 38007 Summary: Records created through Acquisitions with Acquisitions framework are saved in Default Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To Replicate: 1. Ensure the system preference UseACQFrameworkForBiblioRecords is set to use. 2. Ensure an item is created when order is placed in the vendor configuration. 3. Create a basket and add an empty record. Fill any a few fields. 4. Click on the title of the record from the basket and view the bibliographic detail view. 5. Note the record has been saved as Default even though the record was created with the Acquisitions framework. I would have expected records created through Acquisitions with the Acquisitions framework would have been saved in the Acquisitions framework. While it is possible to find records created in this way by searching a basket, it would be really nice to find records created in acquisitions with the acquisitions framework and to have the record display more accurately. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 35575] New: Acquisition framework fails to display required next 942 $C when defined as mandatory
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35575 Bug ID: 35575 Summary: Acquisition framework fails to display required next 942 $C when defined as mandatory Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate 1. Ensure the acquisition framework includes the 942 $C. Mark this field as mandatory. 2. Add to basket from a new record (or other method) 3. See the Item type drop down does not display required. With the 942 $C included in the framework, the item type displays the first alphabetically listed option, which may be wrong if the correct option is not selected. In a way this makes the field "required" by default. There is no "blank" option. Is having the first option pre-selected by default desired behavior? Should it default to a blank option instead? Further, if a field is marked as mandatory, shouldn't there be a Required in red next to the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 23232] New: Enable the option to use the onscreen keyboard on the basic cataloguing editor
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23232 Bug ID: 23232 Summary: Enable the option to use the onscreen keyboard on the basic cataloguing editor Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: koha-bugs(a)lists.koha-community.org, m.de.rooy(a)rijksmuseum.nl, testopia(a)bugs.koha-community.org Depends on: 17178, 23231 Bug 17178 introduced the Mottie on screen keyboard https://github.com/Mottie/Keyboard for the advanced cataloguing screen. It would be helpful to have this option available on the standard editor as well. Catalogers may still have the requirement to enter foreign or special characters when in this mode. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17178 [Bug 17178] Add a popup/keyboard shortcuts for diacritics and symbols in the advanced cataloging editor https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23231 [Bug 23231] We display too many layout options for the onscreen keyboard in the advanced cataloguing editor -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are on the CC list for the bug.

1 13

[Bug 39892] New: Search results: .results_summary > .label isn't high enough color contrast
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39892 Bug ID: 39892 Summary: Search results: .results_summary > .label isn't high enough color contrast Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com 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 If you do a catalog search that returns results on the staff interface the search results table background alternates between white (#fff) and gray (#f3f4f4). The class .label has a color of #707070. This fails color contrast tests: Normal Text WCAG AA: Fail WCAG AAA: Fail -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0