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

[Bug 26835] New: Ability to remove Lost Items from Patrons Account without Checking in
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26835 Bug ID: 26835 Summary: Ability to remove Lost Items from Patrons Account without Checking in 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Libraries all have unique ways of handling lost statuses. At the moment, Koha allows libraries to remove a lost item from the patron's account when set to a lost status and also to not remove it. Great! However, we would like to see Koha go one step forward after the library chooses to not remove the lost item from the patron's account, to allow for the item to be removed at a later date. A preference would be to have the Batch Item Modification allow for libraries to change an item's lost status to another lost status, and also remove it from the patron's account. Using the batch item modification will allow for libraries to do this operation in bulk ! Currently, if a library has the option to credit the patron if they do return a lost item, the library has no way of telling Koha (at check-in) don't refund, don't remove the lost status, just remove it from the patron's account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31525] New: Street number not being accessed correctly on patron search results page
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '22

15 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31525 Bug ID: 31525 Summary: Street number not being accessed correctly on patron search results page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you use the streetnumber field in the patron form, this doesn't show with the address in patron search results. To reproduce: 1) Edit a patron's contact information 2) Under Main Address put an address, make sure to put something in the Street number field 3) Do a simple patron search that will yield results (i.e. "a") 4) Confirm the street number does not show, but the rest of the address does -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 23541] New: Duplicate Hold Notifications
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '22

15 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23541 Bug ID: 23541 Summary: Duplicate Hold Notifications Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In 18.11, it was reported that library patrons from several libraries were receiving duplicate hold notifications. This is not performing consistently, and hard to reproduce. Both Firefox and Chrome browsers have performed the same way. It would appear that the hold request has been sent twice and unfortunately, it can't be determined what is causing this. The patrons that have received duplicate hold notifications don't consistently get the duplicate hold notification, it is quite random. This duplicate hold notifications are occurring in Email form and a variety of email providers are doing this. These duplicate hold notifications are happening on holds on the shelf and checked in holds, this is happening sporadically during the day. The libraries that have reported this are not using SIP devices and only one is using a RFID scanner. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 30314] New: Microsoft font makes extra space in OPAC with Chrome, Edge, and Vivaldi browsers
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '22

15 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30314 Bug ID: 30314 Summary: Microsoft font makes extra space in OPAC with Chrome, Edge, and Vivaldi browsers Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Browser compatibility Assignee: oleonard(a)myacpl.org Reporter: frank(a)sydt.com.tw QA Contact: testopia(a)bugs.koha-community.org Created attachment 131850 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=131850&action=e… Compare issue between Firefox and other browsers Dear All, We found an issue when using Microsoft font like the attached file in OPAC. When we set the font from Microsoft to Google font. The problem is fixed. The engineer said those browsers who had this issue, within the code, found an extra "user agentstylesheet" from Google. It seems not to influence the system work, but one Koha user reports this to us. So, we also report here and hope it is not a serious problem for all Koha users. Best regards, Frank Chou Shou Yang Digital Technology Co., Ltd. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 31636] New: Add part_number and part_name in opac browse search
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '22

15 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31636 Bug ID: 31636 Summary: Add part_number and part_name in opac browse search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When using OpacBrowseSearch (with Elasticsearch), the browse results only show the main title (245$a in MARC21). It would be nice to also show the part_number (245$n) and part_name (245$p) so that series titles can be differentiated. I included a .mrc file with sample records of two series (MARC21). If you want to use your own records, search for or create records for a series that has the main title in 245$a and the volume number in 245$n and the volume title in 245$p. To test: 1. Download the sample records and import into Koha 1.1. Download the sample mrc file 1.2. In Koha staff interface, go to Tools > Stage MARC records for import 1.3. Click 'Browse' and choose the file 1.4. Click 'Upload file' 1.5. Click 'Stage for import' 1.6. Click 'Manage staged records' 1.7. Click 'Import this batch into the catalog' 2. Make sure OpacBrowseSearch is enabled 2.1. In Koha staff interface, go to Administration > Global system preferences 2.2. Search for OpacBrowseSearch 2.3. If necessary, change to 'enable' and click 'Save all OPAC preferences' 3. Make sure you are using Elasticsearch, as OpacBrowseSearch only works with ES 3.1. In Koha staff interface, go to Administration > Global system preferences 3.2. Search for searchengine 3.3. If necessary, change to 'Elasticsearch' and click 'Save all Administration preferences' 4. In OPAC, use the browse search to search for Addison 4.1. In Koha OPAC, click on 'Browse search' 4.2. Search for Addison 4.3. Click on the author's name 'Addison, Marilou,' --> Note that all results are for 'BFF' with no other title information -- it would be nice to have part_number and part_name here -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 28420] New: Allow login via AzureAD OpenID-Connect
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '22

15 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28420 Bug ID: 28420 Summary: Allow login via AzureAD OpenID-Connect 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: mark.jaroski(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Hi, At the World Health Organization our South-East Asian regional office uses Koha for their regional library, with access by all WHO staff in the region and selected staff worldwide. Since local user databases can present a security risk we require that all applications for staff be integrated with our identity provider which at the moment is Microsoft's AzureAD. AzureAD uses OpenID-Connect and is mostly drop-in compatible with Google's implementation, with the exception that in order to construct the URLs both for redirection and for validation you need to know the organization's Azure tenant ID. Because our system integrator is not interested in pursuing this integration I've taken it on myself, and so I've set up a development environment and have started working on the code. My plan is to set up the configuration parameters and to then use them in a very slightly altered copy of the current googleopenidconnect file. I think in the long run it would be better to have a generic OpenID-Connect configuration to allow integrations with other providers like Okta and OneLogin, but we don't need for the moment that so for now I'll just add the AzureAD provider. I'll read up on the rest of the contribution procedure, and I'll be back with a patch/PR in a few days. Best, Mark -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 30344] New: Changing a patron from a category that allows guarantors to one that doesn't should remove that link
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '22

14 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30344 Bug ID: 30344 Summary: Changing a patron from a category that allows guarantors to one that doesn't should remove that link 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a child typo patron is changed to an adult type patron, it hides the patron's guarantors, but does not remove that link. We should be removing that link. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 30351] New: Changing a patron type should warn librarian if a guarantor/guarantee relationship will be severed
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '22

14 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30351 Bug ID: 30351 Summary: Changing a patron type should warn librarian if a guarantor/guarantee relationship will be severed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Right now, if a librarian changes a child with guarantors to and adult, or an adult with guarantees to a child ( via Bug 30344 ), the relationship is severed automatically. It would be nice if there was a warning that this is going to happen. I'm thinking we could just have a warning show up beside the patron category selector if the new patron category would result in either guarantor relationships or guarantee relationships being severed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 31530] New: HTML tags in TT comments in patron-search.inc
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '22

14 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31530 Bug ID: 31530 Summary: HTML tags in TT comments in patron-search.inc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In patron-search.inc there is a TT comment block using <xxx>, this can be confused with real HTML tags. It shows in translation strings. I propose to use simple text. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 31483] New: Minor UI problem in opac-reset-password.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '22

14 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31483 Bug ID: 31483 Summary: Minor UI problem in opac-reset-password.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When EnableExpiredPasswordReset is enabled, patrons can access a page to reset their password. In this page, the grey box that normally contains the breadcrumbs encompasses the whole form. To test: 1) Enable EnableExpiredPasswordReset 2) Find a patron and change their password so you know what it is supposed to be 3) In the database, expire the patron's password, e.g. UPDATE borrowers SET password_expiration_date = '2022-08-22' where borrowernumber = 21; 4) Go to the OPAC, try to log in with the patron's credentials 5) Click Reset your password => Note that the form is in the grey breadcrumbs box, you can compare with any other OPAC page, the grey box should only contain the breadcrumbs -- You are receiving this mail because: You are watching all bug changes.

1 21