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

[Bug 29945] New: Item Level Hold Library Location
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29945 Bug ID: 29945 Summary: Item Level Hold Library Location Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: daniel.gaghan(a)pueblolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Item level holds ignores selected hold pick up location and reverts to library location of staff who placed the hold. Method of replicating this bug. 1. Set Staff Location to Library B 2. Place a item level hold item for a user to pick material at Library A 3. After hold has been placed review pick up location. Results: Library Pick up location will be Library B, not Library A. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29937] New: class close, close the full windows
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29937 Bug ID: 29937 Summary: class close, close the full windows Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org Good morning we have found something it could be an issue or not.. ;) https://github.com/Koha-Community/Koha/blob/master/koha-tmpl/opac-tmpl/boot… $(document).ready(function(){ $(".close").click(function(){ window.close(); }); the issue is basically that we assign a class $('.close') to do window.close() We do have that handler bound to the class close, which can be considered a bit loose in scope and lead to clashes. We have added a js on mainuserblock with .close, and when it clicks, close the full browser tab ;), of course we can change the class, but I think it is something to consider if change that code ;) cheers -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 29902] New: While upgrading all empty deleteditems.datelastborrowed turned deleteditems.timestamp to date of upgrade
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29902 Bug ID: 29902 Summary: While upgrading all empty deleteditems.datelastborrowed turned deleteditems.timestamp to date of upgrade Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: edv(a)hoernergruppe.de QA Contact: testopia(a)bugs.koha-community.org After upgrading from 19.06 to latest we recognized in our deleted items report a wrong amount of deleted items for 2021. Digging onto the problem we found, that every dataset in deleteditems with an empty deleteditems.datelastborrowed field, caused a deleteditems.timestamp set to the actual date by overwriting the former content of the field. We got the former content back by importing additionally the old database so called "koha_library_old" and the follwing SQL request (2021-12-01 was the date of our upgrade) UPDATE koha_library.deleteditems, koha_library_old.deleteditems SET koha_library.deleteditems.timestamp = koha_library_old.deleteditems.timestamp WHERE koha_library.deleteditems.barcode = koha_library_old.deleteditems.barcode AND koha_library.deleteditems.timestamp LIKE '2021-12-01%'; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22833] New: Don't let users cancel holds connected with ILLs
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22833 Bug ID: 22833 Summary: Don't let users cancel holds connected with ILLs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- In the Swedish (Libris) ILL module, when a new ILL request is created, a record and an item (with a specific ILL itemtype) are also created. And a hold is created between the local patron that is waiting for the ILL and the local ILL item. This means that the ILL shows up as a regular hold when the patron logs into the OPAC. That in it self is OK, but the problematic thing is that patrons can cancel the holds connected with the ILL (maybe thinking that they are then also canceling the ILL request). Libraries would like to stop patrons from doing this. A couple of options come to mind: 1. Add a syspref that can take a list of itemtypes that should not be cancel'able by the patron in the OPAC 2. Add a boolean field like itetypes.let_patrons_cancel_holds_in_opac which defaults to 1 for existing itemtypes, but can be set to 0 to achieve the desired effect. 1 is more unobtrusive, 2 is probably cleaner in the long run? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 29851] New: Prevent cancellation by patron of certain holds
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29851 Bug ID: 29851 Summary: Prevent cancellation by patron of certain holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 We have partner libraries using the ILL module with a backend that generates holds. If the patron cancels the hold via the OPAC, it fouls up the ILL workflow. It'd be great to have a method to prevent these holds from being cancelled by the patron (without preventing patron-instigated cancellation of *all* holds). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 29839] New: elastic search non default authorities
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29839 Bug ID: 29839 Summary: elastic search non default authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es ElasticSearch is not able to index authorities no configured at koha as default, rebuild gets this error Can't locate object method "type" via package "Can't call method "tag" on an undefined value at /usr/share/koha/lib/C4/Heading.pm line 71. " (perhaps you forgot to load "Can't call method "tag" on an undefined value at /usr/share/koha/lib/C4/Heading.pm line 71. "?) at rebuild_elasticsearch.pl line 312. If a customer has added a new authoriy like 147, ES is not able to index it, it is not a very common issue, but it could happen. Authorities at koha are hardcoded and you can 't add on web admin Kindest regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29774] New: Self registration notification management
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29774 Bug ID: 29774 Summary: Self registration notification management Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Self registration notifications do not appear to be stored in the patron record under notices. While there is sensitive information in the notice that could be masked to staff, it would be helpful if there was a record of this notice on our end, and a way to resend (with new self-generated passwords when appropriate). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29726] New: ulactioncontainer on opac-detail.pl needs to be closer to top on small devices
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29726 Bug ID: 29726 Summary: ulactioncontainer on opac-detail.pl needs to be closer to top on small devices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org With recent changes to bootstrap, the OPAC now throws the ulactioncontainer (which is in div.col-lg-3) all the way to the bottom of the screen. This is annoying if you are on a small device and your library has lots of details and add-ons (like Novelist Select). Users on small devices have to do a lot of scrolling to do anything. The ulactioncontainer would be better placed either under #catalogue_detail_biblio, or as popup menu under a 3 bar menu icon when viewed on a small device. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 29659] New: QR Code Accompanying material
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29659 Bug ID: 29659 Summary: QR Code Accompanying material Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: infoscienceaddict(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some newer printed book editions include QR codes linking to sound recordings of the content or other material. Could there be a way to add these QR codes in the bibliographic record so that users can actually scan and listen to / watch / see the content (provided that all rights are reserved etc.)? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 29619] New: Ordering single item does not save item as Ordered
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29619 Bug ID: 29619 Summary: Ordering single item does not save item as Ordered Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: minna.kivinen(a)hamk.fi QA Contact: testopia(a)bugs.koha-community.org When ordering just one item, the item does not get "Not for loan" -value "Ordered". When function "Add more items" is used to put item(s) to order, the item(s) get value "Ordered". (Even if you that way add only one item). Path to get the bug: Find a vendor and a acquisition basket Choose "Add to basket" Find title to order - Choose "Add order" Edit item details (do not touch Not for loan value). Choose "Add item". Save new order. -> result: item is added as available (Should be Ordered) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8