March 2018 - Koha-bugs - lists.koha-community.org

[Bug 18983] New: koha-create does not default to --create-db
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18983 Bug ID: 18983 Summary: koha-create does not default to --create-db Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: CJSH(a)CJSHayward.com QA Contact: testopia(a)bugs.koha-community.org I reported in an email on the list that, after clearing away previous and possibly conflicting material, I found a .in file in /etc but didn't see how to make an appropriate koha-conf.xml. The reply I received was that there was apparently an issue that "koha-create library" should, by default, behave as if "koha-create --create-db library" had been entered. However, it did not. When I ran "koha-create --create-db library" it worked further and populated /etc/koha/sites/library with several configuration files. N.B. I got further, but I do not yet have a real site (attempting to configure the webinstaller gets redirected to a maintenance mode page at /cgi-bin/koha/maintenance.pl); however, that may be a separate issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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 17291] New: Add <item>...</item> syntax to advance_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '25

15 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17291 Bug ID: 17291 Summary: Add <item>...</item> syntax to advance_notices.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org advance_notices.pl, which handles DUE, DUEDGST, PREDUE and PREDUEDGST notices, does *NOT* accept the <item> ... </item> Syntax used by overdue notices. This is *VERY* confusing to users -- It's one of the most frequent trouble tickets handled by Bywater Solutions. As far as I can tell, there's no reason *not* to fix this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 16734] New: getLanguages() in opac-search.pl should be called only if needed
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16734 Bug ID: 16734 Summary: getLanguages() in opac-search.pl should be called only if needed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org There is no need to always call getLanguages() in opac/opac-search.pl (especially not if it's an actual search), it's output is used only in opac-advsearch.tt template. This patch moves it into 'if ( ... $template_type eq 'advsearch' )' block. Speed gain is rather moderate (40 - 80 msec, if the mysql server is no too busy, and the results are already in query cache), but it eliminates a lot of small DBI calls, making a further profiling of OPAC searches a bit easier. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 19859] New: Add option to return to the search result in authorities
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19859 Bug ID: 19859 Summary: Add option to return to the search result in authorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, It is imposible to return to hte result search when you edit an authorities in a record. When we want to edit an authorities in a record, we can clic on the tag editor. That option will open a search page. In this search page you can search authorities. If you clic on edit authorities that action will be open into the authorities module. If you clic on save, you stay in authorities module and you don't return on the search page of the tag editor. Because of that, if you had made some changes in the authoritie, you can't clic on choose for linking to the record. To recreate: Go to a record Edit an authoritie with tag editor Search an authoritie with this plugin Choose an authoritie and clic on edit authorities Clic on Save Notice that you still in the authorities modul and you can’t link this authoritie in your record. For make this link you have to "go back" two times ank clic on choose or make this search another time. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 18595] New: Move C4::Members::Messaging to Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18595 Bug ID: 18595 Summary: Move C4::Members::Messaging to Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Bug 17499 adds Koha-objects for messaging preferences. -- You are receiving this mail because: You are watching all bug changes.

1 159

[Bug 19919] New: Writing off a Lost Item Fee marks as "Paid for by patron"
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '24

26 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19919 Bug ID: 19919 Summary: Writing off a Lost Item Fee marks as "Paid for by patron" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 70293 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=70293&action=ed… An example A replacement copy was ordered for an item that was "long lost overdue" on a patron's account. The librarian wanted the old copy deleted from the system to keep the record clean. We checked in the item, marked it as lost, and then wrote off the fee associated with the item. Finally we reapplied the fee manually, no longer associated with the item. We noticed that at the point of the write off, the item gets a line that says paid for by (Patron name and barcode) DATE TIME. This also happens if the book is checked in and no longer marked as lost (say it was returned by the borrower so we wrote off the lost item fee.) The borrower has not paid for the book in either situation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 76