July 2016 - 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 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 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 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 15725] New: Merge permission
by bugzilla-daemon＠bugs.koha-community.org 25 Dec '24

25 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15725 Bug ID: 15725 Summary: Merge permission Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if Koha had a permission to limit access to the merge records option (Merge selected button) on the addbooks.pl search results page and the virtualshelves/shelves.pl page (lists). This is especially important in a consortial catalog environment where many people have cataloging permissions, but most probably shouldn't have the ability to merge records. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 16694] New: Limit SIP2 auth by patron attribute
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '24

10 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16694 Bug ID: 16694 Summary: Limit SIP2 auth by patron attribute Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org In Scandinavia "more open" (Swedish: "Meröppet", Norwegian: "Meråpent") is a hot issue at the moment. What this means is that patrons can use their card and password/PIN to lock themselves into the library even when staff is not around. Typically, this means that patrons can get access to the library building from 7 am to 11 pm, even if the library is only staffed from 8 am to 5 pm. Typically, SIP2 is used to communnicate between the "more open"-system and the ILS, specifically to authenticate the user with a username and password/PIN. Also, you want the ability to turn "more open" access on and off for patrons. An extended patron attribute with possible values of NULL/empty, 0 or 1 should serve well for this. SIP2 does not have a field for saying "this is a moreopen login", so we need a way to identify a SIP2 user as a moreopen user. My plan is to add another attribute to the login element in SIPConfig.xml to achieve this: <login id="koha" password="koha" delimiter="|" error-detect="enabled" institution="kohalibrary" patron-attribute="MEROPPET" /> "MEROPPET" is then the name of an extended patron attribute which can be set to NULL or 0 (patron should not have access to moreopen) or 1 (patron should have access). This should be flexible enough to allow other, similar schemes to use some other patron attribute. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 16846] New: Move patron related code to Koha::Patron
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '24

19 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16846 Bug ID: 16846 Summary: Move patron related code to Koha::Patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement 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 -- You are receiving this mail because: You are watching all bug changes.

1 70

[Bug 16264] New: Confirm message on deleting an authority framework subfield
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16264 Bug ID: 16264 Summary: Confirm message on deleting an authority framework subfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Just using this as an example because it appears in many places on the intranet Is there a reason that we navigate to a new page to confirm or cancel a delete rather than just using a Javascript confirm message? A JS message would use much less code. I realise that in the past we had a rule that everything had to work without JS enabled but a lot of stuff on the intranet wouldn't work at all without JS so I'm not sure how much that applies anymore. Anyway, just wondering if these extra pages for confirm or cancelling a delete are still necessary or if we can do this via JS now :) -- You are receiving this mail because: You are watching all bug changes.

1 6