November 2023 - Koha-bugs - lists.koha-community.org

[Bug 28141] New: Accessibility: OPAC Advanced Search fields aren't labelled
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '25

03 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28141 Bug ID: 28141 Summary: Accessibility: OPAC Advanced Search fields aren't labelled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bolshawh(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org The OPAC advanced search page has unlabelled search fields making them inaccessible to users of screen readers. This is a complicated page to get right and I'm not entirely sure how best to fix this. Here are some of the issues with the page currently: Example issue 1: When using NVDA to access the search form fields out of context, it is hard to tell which index (keyword, author, title etc.) you are searching. This is an issue when searching multiple fields at once. "Enter search terms; edit; has auto complete" It would be better if the search form field was linked to the index combo box. We could use aria-labelledby but there may be better ways to do this. Example Issue 2: The label for "search-field_0" is blank. Example Issue 3: The search terms are linked by 'and' but this isn't entirely clear out of context using a screen reader: " ;combo box; collapsed; Subject" "and;combo box; collapsed; Title" "and;combo box; collapsed; Publisher Location" "Location and availability:; combo box; collapsed; All Libraries" "Sort by:; combo box; collapsed; Relevance" "Language; combo box; collapsed; No Limit" Example Issue 4: The remove field buttons aren't programmatically linked to the field they are removing -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 19772] New: Wrong success message if PATRON_NOTE is not defined
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '25

03 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19772 Bug ID: 19772 Summary: Wrong success message if PATRON_NOTE is not defined Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: aleisha(a)catalyst.net.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 14224 There is no PATRON_NOTE notice template created for new installation. If the pref (AllowCheckoutNotes) is set to on, a patron can let a note from the OPAC and the message "Your note about $TITLE / has been saved and sent to the library." is display to the screen. But actually the Koha logs mention "No circulation PATRON_NOTE letter transported by email at /home/vagrant/kohaclone/C4/Letters.pm line 697." and no notice is generated Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14224 [Bug 14224] patron notes about item shown at check in -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 28638] New: Provide authority records via OAI-PMH
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '25

28 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28638 Bug ID: 28638 Summary: Provide authority records via OAI-PMH Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hi, Now Koha only offers bibliographic records via OAI-PMH. We would like to extend the functionality for authority records as well. Michal -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 30329] New: Make URLLinkText configurable separately for items and bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '25

27 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30329 Bug ID: 30329 Summary: Make URLLinkText configurable separately for items and bibliographic records Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Bug 15352 changed the item record link from showing the URL to showing the text defined in the URLLinkText preference. You can now only empty out the pref and affect both bibliographic records and items to undo the change or accept that both show the same text. For the item URLs the use case is often a little different than for the ones in the bibliographic record so it would be nice to have this configurable separately which should also allow to opt for using the old behaviour of showing the URLs as is in the item records. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 34708] New: Ability to modify an orderline to increase quantity of ordered item
by bugzilla-daemon＠bugs.koha-community.org 24 Feb '25

24 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34708 Bug ID: 34708 Summary: Ability to modify an orderline to increase quantity of ordered item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Baskets that create an item when placing an order do NOT allow you to modify the order and increase the quantity. The only time a quantity can be increased is upon receiving. We'd like to be able to modify orders in an open basket and increase the quantity. This does not apply to baskets that create an item when receiving an order or cataloguing as you can modify these orders and increase the quantity. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 30188] New: Hold ratios report is broken
by bugzilla-daemon＠bugs.koha-community.org 24 Feb '25

24 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30188 Bug ID: 30188 Summary: Hold ratios report is broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com When trying to access the report I et: CGI::Compile::ROOT::kohadevbox_koha_circ_reserveratios_2epl::reserveratios_2epl(): DBI Exception: DBD::mysql::st execute failed: 'koha_kohadev.reserves.reservedate' isn't in GROUP BY at /usr/share/perl5/CGI/Emulate/PSGI.pm line 30 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 Testing on ktd with sample database. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 35184] New: Consolidate UNIMARC value builders for 100, 124, 125, 125
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '25

23 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35184 Bug ID: 35184 Summary: Consolidate UNIMARC value builders for 100, 124, 125, 125 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It looks like all these plugins do the same. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32498] New: Checking an in-transit item out at a branch other than the tobranch should cancel the transfer rather than complete it
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32498 Bug ID: 32498 Summary: Checking an in-transit item out at a branch other than the tobranch should cancel the transfer rather than complete it Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com If an item is mid-transfer and gets checked out at a branch other than its tobranch, Koha marks the transfer as arrived and edits the tobranch to be the branch at which the checkout happens. This makes for a confusing data trail. Instead, the transfer should be cancelled and the original tobranch should be retained. https://github.com/Koha-Community/Koha/blob/c7a995d28f7ae3759ec9ad377b5f7f2… To recreate: 1: Start a manual transfer of an item from Branch A to Branch B 2: Confirm the item shows as in transit and the branchtransfers table shows frombranch=A, tobranch=B 3: Check item out at Branch A 4: Confirm the branchtransfers table now shows frombranch=A, tobranch=A, has a datearrived value, and has a comment "Forced branchtransfer" (or, if the checkout happens at a third branch) 5: Start a manual transfer of an item from Branch A to Branch B 6: Confirm the item shows as in transit and the branchtransfers table shows frombranch=A, tobranch=B 7: Check item out at Branch C 8: Confirm the branchtransfers table now shows frombranch=A, tobranch=C, has a datearrived value, and has a comment "Forced branchtransfer" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32438] New: Pseudonymized_transactions should include payments and writeoffs
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32438 Bug ID: 32438 Summary: Pseudonymized_transactions should include payments and writeoffs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Depends on: 24151 The pseudonymization process aims to duplicate the transactional circulation data from the statistics table in a way that does not allow borrowers to be identified. The statistics table also includes entries for payments and writeoffs that contain the borrowernumber of the impacted patron. We should also record payments and writeoffs in pseudonymized_transactions when pseudonymization is enabled. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24151 [Bug 24151] Add a pseudonymization process for patrons and transactions -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 34128] New: Series entry in the 490 field causes the ordering of items to change in the holdings table
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Bug ID: 34128 Summary: Series entry in the 490 field causes the ordering of items to change in the holdings table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The presence of a series entry in the 490 field causes the ordering of items to change in the holdings table. The different ordering is designed to display serial/journal items correctly but it shouldn't be triggered by a 490 entry for a "Books" item type To replicate: 1) In cataloging, click on New record 2) Fill in all the required fields with generic data, ensuring that the 942c field (Koha item type) is "Books" 3) In the 490a field - fill in any string as the Series statement 4) Click save 5) You should now be on the Add item page. We need to add 3+ items, making sure that the Home and Current libraries for each item are in reverse alphabetical order. e.g. Item 1: - Home library: Midway - Current library: Midway Item 2: - Home library: Fairview - Current library: Fairview Item 1: - Home library: Centerville - Current library: Centerville 6) In the top searchbar, find your new item that you have just added 7) On the item detail page, the holdings table will be displaying the items in reverse alphabetical order by library rather than in alphabetical order as it should be by default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18