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

[Bug 36461] New: Advanced editor should disable RequireJS timeout with waitSeconds: 0
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36461 Bug ID: 36461 Summary: Advanced editor should disable RequireJS timeout with waitSeconds: 0 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We currently set waitSeconds: 30 for RequireJS in the advanced editor, which as bug 35799 says just causes loading of the editor to hang forever if loading any required part (which practially speaking means loading svc/cataloguing/framework) takes more than 30 seconds. As jrburke says in https://github.com/requirejs/requirejs/issues/787 waitSeconds exists to show developers why things aren't working when they try to require something that 404s, and to allow error handling in old versions of IE. But since we aren't doing any error handling, we'd be better off setting it to 0, which disables the timeout, and just letting things load no matter how long they take. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 27363] New: Restore temporary selection of Z39.50 targets throughout multiple searches
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27363 Bug ID: 27363 Summary: Restore temporary selection of Z39.50 targets throughout multiple searches Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Prior to 20.05.06, when using Z39.50 in the Advanced Cataloging Editor, servers that were selected each time a new Z39.50 search was done would be retained throughout multiple searches. This is no longer the case. It would be helpful if that behavior was restored. We have preselected servers which persist for all searches. As we catalog we add some additional servers that would be retained for a short period of time until we decided we no longer needed them. For instance, we may be cataloging Spanish and we could check a server that could be used for several bibs but it wasn't a server that we wanted to be a preselected server. Now that a newly checked server is not retained in the short term we have to check it again for every search which is much less efficient. We could go into Admin and make it a preselected search for the short duration we plan to use it and then go back into Admin to uncheck it when done but that is also not efficient. It would be so much more efficient to be able to check a new server, have it retained, and then uncheck it when done. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 36998] New: 'Issue refund' modal on registers.pl can mistakenly display amount from previously clicked on transaction
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36998 Bug ID: 36998 Summary: 'Issue refund' modal on registers.pl can mistakenly display amount from previously clicked on transaction Change sponsored?: --- Product: Koha Version: unspecified 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 In the POS module, the 'Issue refund' modal on registers.pl mistakenly carries forward the amount paid to subsequent modals. Steps to reproduce: -Have the Point of Sale module enabled, a cash register defined and multiple debit types defined -Make multiple sales -View the transaction history for your sales on register.pl -Click on the 'Issue refund' button for one of the sales -Notice that the 'amount paid' displays the amount of the sale -Realize that you selected the wrong transaction for the refund -Find the actual transaction you want to refund and click on the 'Issue refund' button -Notice that the amount listed in the 'amount paid' area is the amount from the first refund you attempted to make, not the amount for the transaction now being handled In the attached screenshots one shows a payment of 3.80. That turned out to be the wrong transaction. Staff then located the correct transaction to be refunded. The amount shows 3.80 (carried over from the previous transaction that was clicked on) but the amount of the original payment was actually 7.40. Not only is the amount of 3.80 incorrect but it is especially confusing since it looks as if you would be refunding more than the original payment. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 36196] New: Handling NULL data in ajax calls for cities
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36196 Bug ID: 36196 Summary: Handling NULL data in ajax calls for cities 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: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello all, Just a simple patch here, I had the case recently, if a data is null in the cities table, the datatable won't handle the data well and will load indefinitely. I've added a condition so that it can be displayed despite NULL data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 25387] New: Avoid merge different type of authorities
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25387 Bug ID: 25387 Summary: Avoid merge different type of authorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When a librarian tries to merge two differents authorities for exampletopic_authority with geogrpahic_authority (Turkey) it deletes one of the authority and all the tags associated for example merging Turkey(topic) with Turkey(geographic) the result is all 650$aTurkey dissapear We should add a lock to avoid merge two different authorities... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 37226] New: Authority hierarchy tree broken when a child (narrower) term appears under more than one parent (greater) term
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37226 Bug ID: 37226 Summary: Authority hierarchy tree broken when a child (narrower) term appears under more than one parent (greater) term Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org Created attachment 168314 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168314&action=e… short screen recording that shows the bug in action With AuthDisplayHierarchy enabled and the following MARC21 authority data: 001 1 151 $a Europe 551 $a Athens $w h $9 3 942 $a GEOGR_NAME 001 2 151 $a Greece 551 $a Athens $w h $9 3 942 $a GEOGR_NAME 001 3 151 $a Athens 551 $a Europe $w g $9 1 551 $a Greece $w g $9 2 942 $a GEOGR_NAME In the authority details page for 'Athens' (authid=3), clicking on the expand/collapse arrows next to the top-level terms in the hierarchy tree ('Europe' and 'Greece') will not work properly, i.e. *only one* broader term will show 'Athens' as its narrower term at any given time. I attach a small screen recording that shows this in action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 29539] New: UNIMARCslimUtils.xsl
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29539 Bug ID: 29539 Summary: UNIMARCslimUtils.xsl Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rafael.antonio(a)sapo.pt QA Contact: testopia(a)bugs.koha-community.org When it hapens UNIMARC record to have $9 after $a on biblio_metadata record like <datafield tag="606" ind1=" " ind2=" "> <subfield code="a">Portugal</subfield> <subfield code="9">12005</subfield> </datafield> OPAC details display the authority number and not the term. If we change record for <datafield tag="606" ind1=" " ind2=" "> <subfield code="9">12005</subfield> <subfield code="a">Portugal</subfield> </datafield> it display the term. Is it a bug? The only piece of XSLT code I see for such reason is at UNIMARCslimUtils.xsl file <xsl:choose> <xsl:when test="marc:subfield[@code=9]"> Any comment? -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 30230] New: Search for patrons in checkout should not require edit_borrowers permission
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30230 Bug ID: 30230 Summary: Search for patrons in checkout should not require edit_borrowers permission 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 15812 made searching for patrons for checkout use the regular patron search. This resulted in a significant change in behavior for users who have _circulate_ permissions but not _edit_borrowers_. Previously, a user with these permissions could enter a partial name, be taken to a list of search results, and select the patron they desire. Following bug 15812, a user with these permissions will hit a "You do not have permissions" block when attempting to search for a partial patron name. One can allow the search by adding _edit_borrowers_ permission, but that also grants the ability to create and edit patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 119

[Bug 35916] New: Purchase suggestions bibliographic filter should be a "contains" search
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35916 Bug ID: 35916 Summary: Purchase suggestions bibliographic filter should be a "contains" search Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Previously, when searching for purchase suggestions, you could search for any word in the title and it would find it. Now, it only finds the title if it's an exact match. To recreate: 1. Create a purchase suggestion with a multi-word title (e.g. one day in december) 1.1. Go to Acquisitions > Suggestions > New purchase suggestion 1.2. Enter a title (e.g. one day in december) 1.3. Click on Submit your suggestion 2. Search for one of the words in the title 2.1. In the "Filter by" section, click on Bibliographic information 2.2. In the title field, enter one of the words of the title (e.g. december) 2.3. Click Go --> No results I only tested with the title and the author, but I think it's valid for all bibliographic elements. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 36589] New: Advanced cataloging - Expand clipboard
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36589 Bug ID: 36589 Summary: Advanced cataloging - Expand clipboard 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I was updating the screenshots for the manual in the advanced editor section and noticed the clipboard is very small compared to before. I don't use the advanced cataloging editor, so I don't know if it's a need for the clipboard to be large or small, but just clicking around, I find it hard to use with it being so small. See the "before" screenshot: https://koha-community.org/manual/23.05/en/html/_images/advancedcataloging.… To get there: 1. Enable the EnableAdvancedCatalogingEditor syspref 2. Search the catalog for a record 3. Click Edit > Edit record 4. Toggle the editor to the advanced editor 5. Click on the content of a field and press Ctrl+C --> The field should be added to the clipboard section on the left side 6. Redo step 5 a couple of times --> All the fields are added to the clipboard section on the left side, but only 1.5ish lines are shown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19