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

[Bug 37253] New: Enhance POST /checkouts endpoint to accept barcode or item_id
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37253 Bug ID: 37253 Summary: Enhance POST /checkouts endpoint to accept barcode or item_id Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com By now a new checkout is built at least by params patron_id and item_id. This makes it a bit difficult if you only have a barcode of the item available, f.e. from RFID middleware applications, as you have to make another API call to retrieve the item_id for a barcode first. I would propose to enhance the POST /checkouts (addCheckout) route to accept either item_id or barcode (external_id in API) as JSON params. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 37446] New: Home/holding library facets missing user friendly label
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37446 Bug ID: 37446 Summary: Home/holding library facets missing user friendly label Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org After upgrading to 24.05, the default Elasticsearch-Koha installation has facets for "Holding libraries" and "homelibrary" (see screenshot). Bug 35138 introduced a search_field atomicupdate that changed holdingbranch and homebranch labels based on DisplayLibraryFacets system preference the following way: "holdinglibrary" => "Holding libraries" "homelibrary" => "Home libraries" If DisplayLibraryFacets was set to "both", both labels would be updated. If not, only one of them is changed. DisplayLibraryFacets defaults to "holding" meaning a default Koha setup would only update "Holding libraries" and leave "homelibrary" as it is. https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=165813&action=d… This creates an unfriendly facet label "homelibrary". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 27063] New: Allow changing which record an order is linked to
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27063 Bug ID: 27063 Summary: Allow changing which record an order is linked to 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment if the basket is still open you can update the bbliographic details of an order or overwrite the existing record via Z39.50, but if you notice that you have used the wrong record, there is no way to fix this. It would be great if it was possible to change the record an order is linked to while the basket is still open. This should explicitly allow to use a record that is already in the catalog. -- There is also a use case here for libraries using standing orders for tracking electronic resources such as series. They usually place the order on the series record. When the volumes arrive they'd like to change it so the acq information is tied to the volume. But without using items (which is not the case here for electronic resources), this is not possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 37109] New: Don't provide old claims fields when duplicating acquisitions orders
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37109 Bug ID: 37109 Summary: Don't provide old claims fields when duplicating acquisitions orders Change sponsored?: --- Product: Koha Version: Main 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 The following fields that used to be in the aqorders table for claims are still initialised when duplicating orders. They aren't stored anywhere so don't cause a problem, but they don't need to be set at all. * claims_count (dropped in Bug 24161) * claimed_date (dropped in Bug 24161) * placed_on (no evidence of this field existing in aqorders) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 32722] New: Mandatory subfields from Unimarc framework shouldn't block the creation of a bib record when field itself is optional.
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Bug ID: 32722 Summary: Mandatory subfields from Unimarc framework shouldn't block the creation of a bib record when field itself is optional. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibault.keromnes(a)univ-paris8.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 145658 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145658&action=e… List of mandatory subfields BZ30733 added many mandatory subfields in UNIMARC default framework, following the IFLA manual updates. Thing is, most of those mandatory subfields are within an optional field, so they're supposed to be mandatory only if the field is used. Yet Koha blocks the record's creation with ~60 mandatory subfields. Most practical solution would probably be to remove the mandatory flag to said subfields (the list is attached to the bug). Exception are 100$a and 200$a (the fields being mandatory too it makes sense) Also have a doubt concerning 099$t and 942$c, that are not actually Unimarc, but Koha specifics, storing biblioitems.itemtype. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65

[Bug 36662] New: ILL - t/db_dependent/Illrequest should not exist
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36662 Bug ID: 36662 Summary: ILL - t/db_dependent/Illrequest should not exist 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 35581 Following up restructuring of ILL classes from bug 35581, the t/db_dependent/Illrequest directory should be deleted and its content moved into t/db_dependent/ILL/Workflow and/or t/db_dependent/ILL/Request Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35581 [Bug 35581] ILL Koha classes are not consistent -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 37529] New: Collapsing Patron Messaging Preferences in Patron Add Form Results in Spinning Wheel
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37529 Bug ID: 37529 Summary: Collapsing Patron Messaging Preferences in Patron Add Form Results in Spinning Wheel Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 169868 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169868&action=e… Spinning wheel in patron add form In the CollapseFieldPatronAddForm system preference, if Patron messaging preferences is selected to collapse, the result in the patron add form is a collapsed field with a spinning wheel for that section. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32638] New: No reason given for why items ignored during MARC import
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32638 Bug ID: 32638 Summary: No reason given for why items ignored during MARC import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In the past, if you had a "coded_location_qualifier" that was too long, the whole MARC import would bust (see bug 30739). That's no longer the case anymore. However, if the item has a "coded_location_qualifier" like "ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789", it will now just be ignored without any more information shown on the Web UI or in the worker logs. You wouldn't be able to troubleshoot this issue without writing your own code changes to Koha... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 22881] New: Trying to clear search history via the navbar X doesn't clear any searches
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22881 Bug ID: 22881 Summary: Trying to clear search history via the navbar X doesn't clear any searches Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To Reproduce: 1) Run a few keyword searches on your Opac. You can be logged in or not, the behavior is the same. 2) Go to 'My Search History' the /cgi-bin/koha/opac-search-history.pl page. 3) Delete your past searches by selecting one or multiple searches and clicking the "Remove Selected Searches" button. You'll get an alert pop-up about what you are about to delete. The searches you selected should delete successfully. 4) Look at the little "x" (next to "Search History" in the Navbar). If you click on this "x" it will give you the exact same alert pop-up, however is you say yes, delete my searches, nothing will be deleted. Either the little "x" should not give you the option to delete searches nor the alert message or it should clear all your saved searches; as if you hit select all and Remove. Otherwise patrons who want to delete their history will be incorrectly lead to believe it was cleared if they don't check /cgi-bin/koha/opac-search-history.pl . -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 25996] New: Changes to debarments should be logged
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25996 Bug ID: 25996 Summary: Changes to debarments should be logged Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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 To recreate: 1 - verify borrower log is enabled 2 - click Edit on a patron 3 - on the edit page click "add a manual restriction" and enter a debarred comment, save the patron 4 - click Edit again, remove your restriction 5 - go to patron modification logs, see the log of your changes 6 - go back to the borrower checkout page, click to the Restrictions tab 7 - add a restriction 8 - delete the restiction 9 - go to patron modification logs, see there is not a log of your changes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46