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

[Bug 19887] New: Two Factor Authentication: Google Authenticator
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19887 Bug ID: 19887 Summary: Two Factor Authentication: Google Authenticator Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Easy two-factor solution for users with smartphones. Google Authenticator and Perl: https://blog.darkpan.com/article/6/Perl-and-Google-Authenticator.html https://debian-administration.org/article/729/Implementing_two_factor_authe… https://github.com/j256/perl-two-factor-auth -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 30564] New: Prevent user in staff interface from setting incorrect pickup location on item-level hold
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30564 Bug ID: 30564 Summary: Prevent user in staff interface from setting incorrect pickup location on item-level hold 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 When placing a hold in the staff interface, we have one pickup location dropdown at the top of the page for bib-level holds, and then separate dropdowns for the pickup location for an item-level hold. The interface here makes it easy to mistakenly place an item-level hold for the wrong pickup location. To recreate: - go to request.pl - change the pickup location at the top of the form - then pick a specific item and click "Place hold" - Koha ignores the change you made to the bib-level dropdown and maintains the default pickup from the item-level line When one changes the bib-level pickup, Koha should automatically change all the item-level locations to match the new selection. If that would result in an invalid pickup location, the item should instead go to a blank pickup so the user is forced to pick something. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29893] New: ElasticSearch Config UI deletes mappings
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29893 Bug ID: 29893 Summary: ElasticSearch Config UI deletes mappings Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at When using the Elasticsearch UI /cgi-bin/koha/admin/searchengine/elasticsearch/mappings.pl to edit search mappings one can quite easily delete a lot of mappings by mistake. To reproduce: * go to /cgi-bin/koha/admin/searchengine/elasticsearch/mappings.pl * click on the "Authorities" Tab * You should see ~ "67 entries" * enter "Heading-Main" into the search field, you now see ~8 entries ("filtered from 67 entries" * Click "save" Button * Go again to the "Autorities" Tab * You now see ~ "8 entries" * All the other entries have been deleted! What obviously happens is that all entries that where filtered due to the search are not submitted to the backend on save. The backend now interprets the missing entries as entries that shall be deleted. And happily deleted them! This totally breaks the search index (after the next index run, or when adding single items), as (eg in the auth-index) "authtype" is no longer indexed. I currently don't have a 21.11 or later version at hand, so maybe this has already been fixed? To fix this bug we would either have to un-hide the filtered entries before submitting the form; change the backend to not deleted missing entries (which means that the delete-action would have to be implemented a bit different); something else? I guess that the first fix is easier, and would also make sense with regard to how that form works. Greetings, domm -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 30582] New: MARC 952$c won't show in OPAC when not linked to category of authorized values
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30582 Bug ID: 30582 Summary: MARC 952$c won't show in OPAC when not linked to category of authorized values Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org The content of MARC 952$c is only shown if MARC 952$c is linked to category of authorized values "LOC". In this case the content of MARC 952$c is shown in the item data field "current library" in both OPAC and staff client. If MARC 952$c is not linked to a category of authorized values, then the content of MARC 952$c is only shown in the staff client, but not in the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23092] New: Transfers should record 'requested' as well as 'sent' and 'arrived' dates.
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23092 Bug ID: 23092 Summary: Transfers should record 'requested' as well as 'sent' and 'arrived' dates. 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The transfers system is very much tied to the Holds/Reserves features at the moment, but slowly some other subsystems are starting to use it too (Stock Rotation, Rotating Collections). For full audit purposes we should record the 'requested' date along with the 'sent' and 'arrived' dates. Currently stock rotation misuses 'sent' to mean 'requested', so the item may have not actually been picked off the shelf, captured at checkin, and put into physical transit to the next library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 30574] New: Cannot add patron
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30574 Bug ID: 30574 Summary: Cannot add patron 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: manojshahu07(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 133519 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=133519&action=e… Cannot add patron There are no patron categories defined. An administrator must define at least one patron category. Error while creating a new patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23112] New: Circulation of ILL items
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23112 Bug ID: 23112 Summary: Circulation of ILL items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Target Milestone: --- The ILL framework we have supports the tracking of ILL requests well, but once the item has arrived at the library there isn't a clear workflow for lending it to the end user. https://wiki.koha-community.org/wiki/ILL_Circulation_RFC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 123

[Bug 14570] Make it possible to add multiple guarantors to a record
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14570 --- Comment #251 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- It seems that the following occurrences of "guarantorid" should have been removed: koha-tmpl/intranet-tmpl/prog/en/includes/patronfields.inc: [%- CASE 'guarantorid' -%]<span>Guarantor ID</span> koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: <a class="btn btn-default btn-xs" href="memberentry.pl?op=modify&borrowernumber=[% patron.borrowernumber | html %]&step=1&guarantorid=[% guarantor.borrowernumber | html %]"><i class="fa fa-pencil"></i> Edit</a> t/db_dependent/Koha/Patrons.t: guarantorid => $guarantor->borrowernumber t/db_dependent/Koha/Patrons.t: guarantorid => $guarantor->borrowernumber t/lib/TestBuilder.pm: # skip when FK points to itself: e.g. borrowers:guarantorid -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25029] New: AllowPatronToControlAutorenewal needs to have a disable setting
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '22

21 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25029 Bug ID: 25029 Summary: AllowPatronToControlAutorenewal needs to have a disable setting Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 The AllowPatronToControlAutorenewal has a Staff or Stand and Patron setting, but it needs to be a master disable switch as well. With it in the staff only position, staff still see a switch for auto renewal in the patron settings, despite that nothing is set in the circulation rules. It would be ideal if AllowPatronToControlAutorenewal had a Disable setting that: * hid the "Allow auto-renewal of items" choice in the Library Management settings for the patron. * hid the three columns in the circulation rules that deal with Auto Renewal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 14797] Cancelling orders with no alert to existing holds
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '22

20 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14797 CB <balestrieri(a)monterey.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |balestrieri(a)monterey.org --- Comment #6 from CB <balestrieri(a)monterey.org> --- My current practice is to cancel the order and delete the Bib record when cancelling an item on order. If we have another copy of the same item on the existing Bib record, koha will not let you delete the Bib record; it will only allow you to cancel the order for the item. This should be fine as far as a hold is concerned, as the hold will now still be in place for the item currently in circulation. As such, koha will not allow you to cancel the order and delete the Bib record if there is a hold on the item (and this is the only item attached to the Bib record). This automatically alerts me that there is a hold on the item. I do not find this "bug" to be an issue in my workflow or with koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0