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

[Bug 42244] New: Fix JS TypeError on patrons ILL table
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42244 Bug ID: 42244 Summary: Fix JS TypeError on patrons ILL table Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com See this comment from Bug 30200 - https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30200#c53 ill-list-table.js assumes that the multipleSelect jQuery plugin has been loaded, but it is not present when viewing the ILL table via a patron's record at /cgi-bin/koha/members/ill-requests.pl?borrowernumber=1234 . There is no need for multipleSelect since it is used in the left-side Status filter on the ILL Requests tab, which is not present on the member's ILL request page. I will write a patch that does a simple check for the multipleSelect plugin before running the code in addStatusOptions(). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 42611] New: Javascript error on readingrec.pl when no reading history
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42611 Bug ID: 42611 Summary: Javascript error on readingrec.pl when no reading history Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com If you start a fresh KTD, open your F12 tools, and go to http://localhost:8081/cgi-bin/koha/members/readingrec.pl?borrowernumber=51 you'll see a Javascript error. It's because we call 'let table_dt = table.DataTable();' when when "table" is not defined. Should be an easy fix. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 42903] New: Mixed-type authority merges should clear 1st indicator in linked bibliographic fields when appropriate
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42903 Bug ID: 42903 Summary: Mixed-type authority merges should clear 1st indicator in linked bibliographic fields when appropriate Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Some types of authority records (such as personal and corporate names) require a 1st indicator in the 1xx field and some (such as topical headings) don't. This 1st indicator is present in the bibliographic record also. When merging authority records of the first type into the second type, Koha is not correctly updating (clearing) the 1st indicator in linked bibliographic fields. For example, a sample merge might be a corporate authority being merged into/replaced by a geographic authority. 110 2_ $aSoviet Union... (1st indicator=2) > 151 __ $aSoviet Union... (1st indicator=blank) Before the merge, bibliographic records linked to the first heading had a subject field with a 1st indicator of 2. 610 20 $aSoviet Union... After the merge those bibliographic records are incorrectly updated to 651 20 $aSoviet Union... The 1st indicator of 2 is no longer correct because the new governing authority record (151 __ $aSoviet Union...) does not have a defined 1st indicator. The bibliographic record should have 651 _0 $aSoviet Union ... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 41655] New: Local OPAC covers are not displayed in OPAC lists
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41655 Bug ID: 41655 Summary: Local OPAC covers are not displayed in OPAC lists Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Local cover images are no longer displayed in OPAC lists since Bug 41078. In Koha versions prior to 25.05.05, local cover images were correctly displayed in OPAC lists. This appears to be a regression. To reproduce 1. Set the system preferences LocalCoverImages and OPACLocalCoverImages to Show. 2. Find a bibliographic record and open the record detail page. 3. Upload a local cover image file for the record. 4. Create a public list and add the record to the list. 5. In the OPAC, open the public list. --> The local cover image is missing. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 1937] Scan barcode with webcam
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1937 --- Comment #18 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Mathieu Saby from comment #16) > The technical solution doesn't really matter for us, but I'm glad to see > that our idea had actually been "in the works" for 16 years, so it wasn't > completely far-fetched. > From what I understand, there's currently no sponsorship? That's right. I posted a proof of concept on bug 23641, and really... this could be done by a Koha plugin. But no one is sponsoring me to work on it, so I have no plans to work on it haha. My time/effort is needed elsewhere... -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 40871] New: voided payments still appear as bankable in the register
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '26

24 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40871 Bug ID: 40871 Summary: voided payments still appear as bankable in the register Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk When voiding a payment, the payment still appears as bankable in the register. To recreate: 1. Make sure registers are turned on and you know the current bankable amount. 2. Make a cash payment on a patron account. 3. Observe the bankable amount on that register has increased (as expected). 4. Void this payment on the patron account. 5. Note that the bankable amount has not decreased. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 28599] New: Add ability to void purchase in point of sale
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '26

24 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28599 Bug ID: 28599 Summary: Add ability to void purchase in point of sale Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23354 If one enters a purchase incorrectly in the point of sale module, one can refund the payments on that purchase in order to correct Koha's understanding of the amount of money the library has taken in. However, those refunds don't do anything to correct the record of how many items were sold. That means that accurate reporting on number of items sold needs to be verifying that none of the payments tied to the purchase have been refunded. It'd be better to be able to just void the whole sale, setting the amounts on the original purchase(s) and payments all to zero, zeroing out the note in the purchase (since we're using that for the quantity of the sale), and giving them a VOID status. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23354 [Bug 23354] Add a 'Point of sale' screen to allow anonymous payments -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 36403] New: Add ability to set default sort order for items that display in the Point of Sale system on pay.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '26

24 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36403 Bug ID: 36403 Summary: Add ability to set default sort order for items that display in the Point of Sale system on pay.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: martin.renvoize(a)ptfs-europe.com CC: martin.renvoize(a)ptfs-europe.com On the Point of Sale page at pay.pl the configure button takes you to the table settings for the invoices table. It would be helpful if those settings also allowed staff to set a default sort order by either code or description. Our use case is as follows: Our Library sells items for the Library, the Friends group and the Library Foundation. As a consequence, we have 30 different types of items that can be sold via the POS system. Our codes mirror the fund codes that are used by our Finance office which is necessary for making our daily deposits to the City. We assigned more easily identifiable descriptions for the items so that staff would be able to use the POS system efficiently at a very busy Information Desk. We purposely named the most used items so that they would sort alphabetically at the top of the list. But the default sort order for the table is by code not description. So it would be very helpful to us to be able to set the default sort order in the table settings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '26

24 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_26_05_candidate |rel_26_11_candidate -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '26

24 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #308 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- (In reply to David Nind from comment #307) > I'd love to test, but there are a lot of patches and comments for this one. > > Is it possible to get a consolidated test plan for this one? Martin previously shared this test plan: https://docs.google.com/document/d/1EeDN9d787zJyN17-86v_owGkbFEn4fyM6iqb3Cz… It might want some updating. -- You are receiving this mail because: You are watching all bug changes.

1 0