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

[Bug 35483] New: Restore item level to record level hold switch in hold table
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35483 Bug ID: 35483 Summary: Restore item level to record level hold switch in hold table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 33575 commit [1] has reverted hold level switch feature added in Bug 31692 commit [2] to holds table. Switching item level holds to record level holds no longer works in the table. Let's restore the feature in this Bug. [1] https://github.com/Koha-Community/Koha/commit/c649f73d029b406a6bad80c31b838… [2] https://github.com/Koha-Community/Koha/commit/b0f49d5dafa4e2dcc05e1e85c13cd… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[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 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 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 33563] New: Enable compatibility with Elasticsearch secure mode
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33563 Bug ID: 33563 Summary: Enable compatibility with Elasticsearch secure mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hi friends, Koha should support authenticated access to Elasticsearch, at the very minimum https://www.elastic.co/guide/en/elasticsearch/reference/current/http-client… and https://www.elastic.co/guide/en/elasticsearch/reference/current/token-authe… We'd need a place to stash our ES configuration information much like we used to for Zebra. koha-conf.xml is probably fine? Obviously open to discussion from the way smarter people here - this is only to get the discussion started, as Elasticsearch will start creating egregious scary logs for every connection complaining about security, starting with version 7. Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 35869] New: Dismissing an OPAC message from SCO logs the user out
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35869 Bug ID: 35869 Summary: Dismissing an OPAC message from SCO logs the user out Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Enable WebBasedSelfCheck 2. Add an OPAC mesaage to a patron account 3. Login to self check ( http://localhost:8080/cgi-bin/koha/sco/sco-main.pl ) 4. Enter your credentials to login 5. See the OPAC message, click dismiss. 6. Notice you are logged out at redirected to: ( http://localhost:8080/cgi-bin/koha/opac-dismiss-message.pl ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20