November 2020 - Koha-bugs - lists.koha-community.org

[Bug 22160] New: OMNIBUS: Transfers enhancements
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '25

27 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 Bug ID: 22160 Summary: OMNIBUS: Transfers enhancements 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 88

[Bug 22013] New: Command line staging: Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202.
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '25

19 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22013 Bug ID: 22013 Summary: Command line staging: Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: simon.hohl(a)dainst.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 83307 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=83307&action=ed… MARC File containing geographical authority data When using stage_file.pl to import authority data (see attachment), I get the warning: Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in regexp compilation at /usr/share/perl5/MARC/Record.pm line 206. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 207. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. That's 28 warnings for 31 records, but I am unable to decide which cause the warning and which do not. Anybody able to find out why a pattern? Cheers -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 26780] New: have a parameter to export authorized-values labels instead of codes.
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '25

17 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26780 Bug ID: 26780 Summary: have a parameter to export authorized-values labels instead of codes. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When exporting biblios to another software it would be nice to be able to export authorized values labels instead of their codes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 26794] New: Item transfer modal may close automatically after a delay
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '25

17 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26794 Bug ID: 26794 Summary: Item transfer modal may close automatically after a delay Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi Koha, We got complains from users that the new item transfer modal is not convenient when using barcode scanner and mouse/keyboard is unavailable. I've made a small javascript to add in intranetuserjs that closes this modal after a delay (here, 3 secs). Some colleagues of mine told me I shall open a BZ to document this, there it is : <pre> /* Close item transfer modal after 3sec */ $('#item-transfer-modal').on('shown.bs.modal', function (e) { window.setTimeout(function () {$('#item-transfer-modal').modal('hide')}, 3000) }); </pre> Best, Arthur from BibLibre's Koha Support -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 23776] New: API comparative documentation for tierce application
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23776 Bug ID: 23776 Summary: API comparative documentation for tierce application 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: claire.hernandez(a)biblibre.com Work in progess: https://wiki.koha-community.org/wiki/API_comparative_usages -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 17618] New: perl-modules Debian package name change
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17618 Bug ID: 17618 Summary: perl-modules Debian package name change Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net The perl-modules package for Perl 5.22 is called perl-modules-5.22. Koha should know about it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 17712] New: Move availability calculation to the Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Bug ID: 17712 Summary: Move availability calculation to the Koha namespace 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: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 57921 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=57921&action=ed… Diagram to proposal for new classes and their relations Currently some availability-related calculations are scattered around in different modules (which alone is not bad) but also in Perl-scripts, like opac-reserve.pl that has some patron related checks, maxreserves and some other. With this problem I think it is confusing for someone to figure out how availability is calculated. This also makes it difficult to implement something new that needs to find out different levels of availabilities. An example of "anything new" would be REST API, which needs to be able to tell different availabilities (biblio/item holdability, checkout availability both anonymously and with patron restrictions etc). As of now, if we simply ask CanBookBeReserved in REST controller, we are completely ignoring patron debarments and fines, and maxreserves system preference. Another problem is that currently there is no unified way of reasoning unavailability between holds and checkouts. There are strings from CanItemBeReserved, then there are HASHrefs with additional parameters from CanBookBeIssued, then some simple checks that may be simply 1 or 0, like IsAvailableForItemLevelRequest. REST API should however return uniform error codes. Also CanItemBeReserved has the problem that it returns the first reason in case of unavailability, and not all of them, if there would be more. An end-user would probably want to know all problems at once instead of fixing one to only find out there is another. My proposal is to move availability-related calculation and checks into Koha namespace. I propose adding a class, Koha::Availability, that is able to contain availability-related information. It would contain methods to easily find out availability status and any reasons to unavailabilities. To represent reasons for unavailability/additional messages/needs for confirmation, I propose objects instead of strings or hashes. These objects could be Koha::Exceptions. Availability calculation could be categorized into Koha::Availability::Calculation's subclasses. Answers to item availability could be located in Koha::Item::Availability::Hold and Koha::Item::Availability::Checkout. This setup would let us have an unified way for handling availability the same way everywhere. How would it work in practice? I will describe my idea with "ingredients" and "recipes": - "ingredient": anything availability-related sub-check or sub-calculation (e.g. item withdrawn, reservesallowed in issuing rules, age restriction etc.) that returns a Koha::Exception::* if it spots a problem. These could be located in Koha::Availability::Calculation subclasses. - "recipe": a set of ingredients that cooks an answer to question "is something available in some way", for example: ** "Q: does an anonymous user see an item available in search result? -> A: no, unavailability reason: Koha::Exceptions::Item::NotForLoan" ** "Q: is an item available for hold for this patron? -> A: yes, additional note: Koha::Exceptions::Item::NotForLoan with parameter code => 'Ordered'" ** "Q: is an item available for checkout for this patron by a librarian -> A: possibly; librarian needs to confirm Koha::Exceptions::Patron::Debt, exception includes field max_outstanding => 10.00, current_outstanding => 15.00" These could be located in Koha::Item/Biblio::Availability::Hold/Checkout The ingredient would contain all logic to spot a problem. The recipe would use what ever ingredients it needs to, and decide if a problem is worth of unavailability, additional note or perhaps ask a confirmation. This is somewhat same as CanBookBeIssued, but the point is to move all calculations away from the recipe so that we can re-use the same logic in another availability recipe. Any thoughts on this idea and current availability in general? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 89

[Bug 16826] New: Add API routes for getting item availability and holdability
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16826 Bug ID: 16826 Summary: Add API routes for getting item availability and holdability Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Add API routes for getting item availability and holdability. Holdability check requires a target borrower (either user himself or borrowernumber). I'm thinking of following endpoints: GET /api/v1/items/{itemnumber}/availability GET /api/v1/items/{itemnumber}/holdability For myself GET /api/v1/items/{itemnumber}/holdability?borrowernumber=X For X Terms: - availability: Does not require login or permissions. Makes a simple check if item is in a valid state for holdings. In other words, check "notforloan", "onloan", "itemlost", "withdrawn", "damaged". - holdability: Requires login and also catalogue permission if the request is made for another borrowernumber than myself. Item is holdable if it is available and if it satisfies IsAvailableForItemLevelRequest and CanItemBeReserved in C4::Reserves + (also debarments and fines?) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 83

[Bug 15855] New: Disabling multiple submission on search form
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15855 Bug ID: 15855 Summary: Disabling multiple submission on search form Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: arthur.suzuki(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 48203 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48203&action=ed… Extract from koha-opac-access_log Some impatient users tends to click several times on the “Go” button of the search form on OPAC. Probably in a desperate hope that this will speed up the whole process. However the result is quite opposite, as Zebra is then queried multiple times which increases the server cpu load, until it reach 100% and cause Denial of Service (boooh…) We had the idea of disabling the “searchsubmit” button upon first click. This is done by adding onclick=”this.disabled=true;this.form.submit();return true;” after “id=searchsubmit” in masthead.inc. It is also possible to solve this issue by adding the following section to opacuser.js: $(document).ready(function() { $('#searchform').submit(function() { $('#searchsubmit').prop('disabled',true).text('searching...'); }); }); Thanks to Frederic Demians and Olivier Crouzet for their help. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 24354] New: Add public API for library information
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '25

16 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24354 Bug ID: 24354 Summary: Add public API for library information 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: oleonard(a)myacpl.org It would be useful in the OPAC to have access to basic library data like address, phone number, web site, OPAC info, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5