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

[Bug 18994] New: Show the branch name where checkin occurred on a title' s Checkout History display
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '25

04 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18994 Bug ID: 18994 Summary: Show the branch name where checkin occurred on a title's Checkout History display Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: techservspec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The Checkout History tab (issue.pl) currently shows the branch name and time stamp for a checkout, but only the time stamp for when it was returned. There are occasions in multi-branch systems when it is helpful to also know where the checkin occurred. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[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 18273] New: Bulkmarcimport inserts authority duplicates
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '25

03 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18273 Bug ID: 18273 Summary: Bulkmarcimport inserts authority duplicates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When importing authorities through bulkmarcimport with the -match option, there are 3 possibilities: 1) An existing authority has been found in koha according to the -match criteria. The authority is replaced if needed (005 are checked first). This is ok. 2) No authority is found in koha according to the -match criteria. The authority is inserted. This is also ok. 3) Multiple authorities have been found in koha according to the -match criteria. The authority is inserted. => Is this the expected behavior? As the -match criteria is used for deduping, the existing authorities are very likely to be already existing duplicates. Do we really want to add another one? My feeling is that in this case, the authority should NOT be inserted. Can I have your opinion on this? -- You are receiving this mail because: You are watching all bug changes.

1 28

[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 18645] New: Creation of informational tool displayed after running Koha update
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '25

02 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18645 Bug ID: 18645 Summary: Creation of informational tool displayed after running Koha update Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com After Koha site admins update their Koha version at present they simply log into the staff interface and the home page is displayed with no further information about what was installed. The enhancement that will be built to fill this niche will display all new sysprefs created since the users previous version by comparing version numbers (old version and new one just installed), the site admin will be able to review and modify the system preferences. Additionally links to the release notes (and manual where applicable) will be provided. If time permitting a further addition to this enhancement would be information about major new features in each release. -- You are receiving this mail because: You are watching all bug changes.

1 41

[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