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

[Bug 20200] New: Show MARC 770 Supplement/Special Issue Entry on detail pages
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20200 Bug ID: 20200 Summary: Show MARC 770 Supplement/Special Issue Entry on detail pages 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently 770 is not shown in Koha on the detail pages. We should add the display of this field. Examples: 770 08 _iAnfangs darin, später selbst. _aGesellschaft für Verbreitung von Volksbildung _tJahresbericht der Gesellschaft für Verbreitung von Volksbildung _dBerlin, 1872 _w015234347 770 08 _iBeil. ab 1902 _aDie Volks-Bibliothek _dBerlin, 1896 _w014944286 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 27901] New: cancelling acq order does not delete item record, causes error
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27901 Bug ID: 27901 Summary: cancelling acq order does not delete item record, causes error Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Prior to 20.05 when an order was cancelled from the basket, the item created when the order was placed was deleted also. In 20.05, users now get the message: An error has occurred. The order has been cancelled, although one or more items could not have been deleted. To recreate: 1. Add biblio and item to basket 2. Cancel the order and delete the biblio 3. Get the error message 4. Verify that the Holdings table still shows the item, but the acq correctly shows the cancellation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[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 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 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 20207] New: Anonymous Purchase Suggestions show on OPAC even when OPACViewOthersSuggestions is set to Don't Show
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '22

14 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20207 Bug ID: 20207 Summary: Anonymous Purchase Suggestions show on OPAC even when OPACViewOthersSuggestions is set to Don't Show 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: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When you enable AnonSuggestions and ALLOW patrons that aren't logged in to make purchase suggestions, once a suggestion has successfully been submitted, Anonymous Purchase Suggestions will show on OPAC even when system preference OPACViewOthersSuggestions, is set to Don't Show. The suggestions will show on opac-suggestions.pl. However, if you search for the title you suggested, you will get a message saying "You are not authorized to see pending purchase suggestions." -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 18232] New: Koha::Cache::flush - Simply flush all caches
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '22

14 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18232 Bug ID: 18232 Summary: Koha::Cache::flush - Simply flush all caches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org This is handy when upgrading Koha or fiddling with config. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 28507] New: Create Koha::Session wrapper to create consistent sessions throughout Koha
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '22

12 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28507 Bug ID: 28507 Summary: Create Koha::Session wrapper to create consistent sessions throughout Koha Change sponsored?: --- Product: Koha Version: master 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, there are a couple different places where authenticated sessions get created. One is checkauth() and another is check_api_auth(). I would also like to create consistently structured authenticated sessions from Koha Plugins. There should be a standard API for creating and fetching sessions. I propose a Koha::Session wrapper. It will define Koha's standard session key set and have some automatic population for things like 'ip' and 'lasttime'. There will also be a method for setting the C4::Context->userenv, which is something that gets done repeatedly in checkauth(), check_api_auth(), check_cookie_auth(), and other less relevant places (like checkpw_internal which is bizarre). I think that this is a reasonable step forward as we add AuthN and AuthZ to things like Koha plugins and Mojolicious controllers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 26114] New: ILL should mark status=RET only if a return happened
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '22

11 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26114 Bug ID: 26114 Summary: ILL should mark status=RET only if a return happened Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com When the C4::Circulation::AddReturn reaches the ILL request update, there are many circumstances under which no return happened, and the ILL code doesn't check that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 24461] New: Add to_api_mapping to Koha::Acquisition::BasketGroup
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '22

11 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24461 Bug ID: 24461 Summary: Add to_api_mapping to Koha::Acquisition::BasketGroup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com We need those mappings for the API. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14