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

[Bug 737] Map of library in search system
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=737 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P5 - low Assignee|oleonard(a)myacpl.org |koha-bugs(a)lists.koha-commun | |ity.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15157] Cronjob to automatically restrict patrons with pending/unpaid charges
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15157 Kyle M Hall (khall) <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39532 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39532 [Bug 39532] Script debar_patrons_with_fines.pl creates repeat restrictions, uses wrong restriction type -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39531] New: Option to retain search terms between searches in z39.50
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39531 Bug ID: 39531 Summary: Option to retain search terms between searches in z39.50 Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If I perform a z39.50 search but don't get the results I need with my selected targets, my search terms are erased when I click 'Try another search' to try the search again with different targets. It would be helpful if search terms were retained by default, perhaps with a 'Clear search terms' button on the main z39.50 search screen for times when libraries do want to clear all terms. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39529] New: Incorrect relationship subfield for unimarc when linking authorities with other authorities
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39529 Bug ID: 39529 Summary: Incorrect relationship subfield for unimarc when linking authorities with other authorities Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: laurence.rault(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org At least from Koha 23.11, in UNIMARC database, when you choose an authority to link with another authority, and select one relationship in the auth_finder, the relation code is added in subfield w, as it is for MARC21. For UNIMARC it should be subfield 5 Test Plan : 0) [PREREQUISITES in order for the authority finder plugin to come up] a) database configured in UNIMARC b) In the SNC (or TOPIC_TERM) authority type c) View the MARC structure, click on 'Actions->Subfields' for tag 550; click on 'Edit subfields'. Select the subfield 'a' tab, then pick an auth type (it could be the same SNC or TOPIC_TERM) from the 'Thesaurus:' dropdown menu; click 'Save changes' at the top. d) In the 550 field, add the subfield w if it does not exists (only to be able to view the problem) 1) In the Staff client, go to Authorities, then click 'New Authority' and pick the 'SNC' (or TOPIC_TERM) authority type (or edit an existing auth). 2) When the authority editor comes up, go to tag 550 and expand it. 3) Click on the ellipsis (...) next to subfield $a. 4) When the authority finder comes up, search for an authority, pick a relator code from the 'Special relationship:' dropdown, and then click on the 'Choose' button for one of the authorities you found. 5) Notice that the code of the relationship is added in subfield w. It should be subfield 5. 5bis) After a suitable patch will be applied : Notice that the code of the relationship is added in subfield 5 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 28608] New: Creating a biblio record leads to item creation even if framework has no items field
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28608 Bug ID: 28608 Summary: Creating a biblio record leads to item creation even if framework has no items field 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some framework for biblio records have no items field (952 in MARC21, 995 in UNIMARC). Records can not have items for example a serial article. In this case creating a record should not lead to item creation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 11904] Proposal for a uniform way to send messages to user interface
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11904 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|In Discussion |RESOLVED --- Comment #60 from Julian Maurice <julian.maurice(a)biblibre.com> --- Closing this one before it reaches the "10 years of inactivity" milestone :) If something like that becomes wanted, patches would probably have to be rewritten from scratch anyway. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39524] New: Bibliographic record created from local ERM title/KBart file contains only the title
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39524 Bug ID: 39524 Summary: Bibliographic record created from local ERM title/KBart file contains only the title Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk According to the manuals page for ERM (https://koha-community.org/manual/24.11/en/html/erm.html#create-a-new-local…) a local bibliographic record with basic fields taken from ERM resource information (publication_title, print_identifier, online_identifier, date_first_issue_online, date_last_issue_online, num_first_vol_online, num_last_vol_online, title_url, first_author, coverage_depth, notes, publisher_name) could be created. However, it seems that a bibliographic record created either from a KBart file line, or from an ERM resource info entered by hand contains only the title (cf. Koha::ERM::EHoldings::Title->store). -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 30816] New: Use of uninitialized value in numeric ge (>=) at /usr/share/koha/lib/C4/Serials.pm
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30816 Bug ID: 30816 Summary: Use of uninitialized value in numeric ge (>=) at /usr/share/koha/lib/C4/Serials.pm Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Blocks: 25790 The code here is: for(my $i = 0; $i < $count; $i++) { if($calc{'X'}) { # check if we have to increase the new value. $newinnerloop1 += 1; if ($newinnerloop1 >= $pattern->{every1}) { $newinnerloop1 = 0; $newlastvalue1 += $pattern->{add1}; } # reset counter if needed. $newlastvalue1 = $pattern->{setto1} if ($newlastvalue1 > $pattern->{whenmorethan1}); } And above: $newinnerloop1 = $subscription->{innerloop1} || 0; I believe this is caused by subscription_numberpatterns.every1 being NULL. The default in the database is NULL, but I haven't tested if this can be set manually from the GUI yet. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25790 [Bug 25790] [OMNIBUS] warnings removal -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 39521] New: Add column to ill_requests table to flag for lending requests
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39521 Bug ID: 39521 Summary: Add column to ill_requests table to flag for lending requests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is for adding a column to flag if a request is a lending request or a borrowing request. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 36684] New: Cancelling an item with uncertain prices leaves the basket marked as a problem
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '25

02 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36684 Bug ID: 36684 Summary: Cancelling an item with uncertain prices leaves the basket marked as a problem Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Issue: When a basket contains an item with an uncertain price, it is flagged as a 'problem.' Baskets cannot be finalized if they include items with uncertain prices. However, if you cancel an order for an item with an uncertain price, the basket still remains marked as a 'problem,' but it can be closed out. This situation might confuse some users who may wonder why their basket is labeled as a problem. This confusion arises because the active items do not display uncertain prices, and there is no way to ascertain whether canceled items were initially marked as uncertain before their cancellation. Suggested resolution: Prevent users from cancelling items with uncertain prices until the uncertain price is cleared/resolved. -- You are receiving this mail because: You are watching all bug changes.

1 5