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

[Bug 30070] New: There are performance issues with edifactmsgs when you have a large number of messages
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '25

23 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30070 Bug ID: 30070 Summary: There are performance issues with edifactmsgs when you have a large number of messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 The edifact messages table can grow to a very large size over time, and the page to display them has issues with this growth as it always loads all messages. We should switch this to an ajax driven datatable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 136

[Bug 29858] New: Item.pm "Use of uninitialized value" warn when $field var is NULL
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '25

20 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29858 Bug ID: 29858 Summary: Item.pm "Use of uninitialized value" warn when $field var is NULL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 6

[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 20 Jan '25

20 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 27872] New: Expand {QUERY_KW} function from OPACNoResultsFound to not-empty search results page
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '25

17 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27872 Bug ID: 27872 Summary: Expand {QUERY_KW} function from OPACNoResultsFound to not-empty search results page 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a patron finds a record but it is unavailable, they can use OPACSearchForTitleIn to look for that same record elsewhere. If a patron finds nothing at all, they can use OPACNoResultsFound to repeat their search in another catalog. But if a patron performs a search that returns *something* but not the thing they want, then they don't have a path to another catalog. We should allow that. -- You are receiving this mail because: 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