February 2017 - Koha-bugs - lists.koha-community.org

[Bug 16104] New: Warnings "used only once: possible typo" should be removed
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '25

18 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16104 Bug ID: 16104 Summary: Warnings "used only once: possible typo" should be removed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Since bug 11998, the following warnings are raised: Name "Tie::Hash::FIELDS" used only once: possible typo at /usr/share/perl/5.22/fields.pm line 135. Name "Cache::RemovalStrategy::LRU::FIELDS" used only once: possible typo at /usr/share/perl/5.22/fields.pm line 135. Name "Cache::RemovalStrategy::FIELDS" used only once: possible typo at /usr/share/perl/5.22/fields.pm line 135. It comes from the Koha::Cache 103 if ( can_load( modules => { 'Cache::Memory' => undef } ) ) { -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 16196] New: Acquisitions Module Not Showing Subtotals
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16196 Bug ID: 16196 Summary: Acquisitions Module Not Showing Subtotals Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Partner reports that when receiving books in the Acquisitions module, subtotals are not identifying which fund they are for. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 17173] New: Quick edit a subfield in frameworks
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17173 Bug ID: 17173 Summary: Quick edit a subfield in frameworks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are too many click to jump to the edit form of a specific subfield. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 17898] New: Add a way to automatically convert SQL reports
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '25

10 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17898 Bug ID: 17898 Summary: Add a way to automatically convert SQL reports Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Bug 17196 move the marcxml out of the biblioitems table. That will break SQL reports using it. It would be handy to propose an automagically way to convert the SQL reports. -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 17791] New: On UNIMARC system, USMARC field 100 gets overwritten
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '25

09 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17791 Bug ID: 17791 Summary: On UNIMARC system, USMARC field 100 gets overwritten Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: synapse.ova(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Overview: On Z39.50 search some functions depend not on the remote server marc flavour, but on current server setting. This bug is present on versions 3.22+ Steps to Reproduce: 1) On UNIMARC system, go to Cataloguing → New from Z39.50/SRU 2) Search USMARC server (Library of Congress, for example) for a book, that has field 100 (for example, isbn 0816310653) 3) On results list, press «MARC» to see MARC fields Actual Results: Instead of seeing the author name in subfield A, you'll see something like «20161219 frey50 », yet you could see other subfields properly Expected Results: Name of the author in 100$a Additional Information: LC Z39.50/SRW/SRU Server Configuration Guidelines: https://www.loc.gov/z3950/lcserver.html -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 16629] New: Fields available for printing are inconsistent between label layouts and SpineLablFormat system preference
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '25

03 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16629 Bug ID: 16629 Summary: Fields available for printing are inconsistent between label layouts and SpineLablFormat system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In label layouts all marc fields are available, however, when setting quick spine fields in the system preferences you can only use columns from the db tables. It would be nice to have access to record fields here as well -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 17390] New: Add REST API endpoint for Authorised Values
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '25

03 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17390 Bug ID: 17390 Summary: Add REST API endpoint for Authorised Values 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be good and useful to at least be able to get the list of authorised values from Koha. The ability to create, update and delete could come later. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[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