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

[Bug 24668] New: Allow users to specify in plugins how often to run the plugin's cron
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '20

02 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24668 Bug ID: 24668 Summary: Allow users to specify in plugins how often to run the plugin's cron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 20897 as an extension of bug 20897, it would be nice for plugin authors to be able to specify when to run a cron. One way to do it might be to have minute, hourly, and daily default crons, and they each check for the timing flag in the plugin config. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20897 [Bug 20897] Add generic cronjob to run plugins with a 'cronjob' method -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20897] New: Add generic cronjob to run plugins with a 'cronjob' method
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '20

02 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20897 Bug ID: 20897 Summary: Add generic cronjob to run plugins with a 'cronjob' method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Sometimes there are ad-hoc cronjobs that need to be setup for a site, or there are plugins that need some regular tasks done. I was thinking an easy solution might be to package a generic cronjob into koha that would run daily (or whenever) to check for plugins with a cronjob method. The plugins could allow for configuration of the job in their configure method so that users could have control over some jobs. Could be used for emailing reports or other things that might benefit from a user facing solution. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 19508] New: When returning a lost item, Koha claim to have applied a refund when it has not
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '20

01 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19508 Bug ID: 19508 Summary: When returning a lost item, Koha claim to have applied a refund when it has not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1) Create a new item 2) Set it to 'missing' from the edit item screen (you might have to change the visibility setting of this subfield in order to do that) 3) Return the item 4) Verify that Koha reports: A refund has been applied to the borrowing patron's account. This message should only be shown, when an actual refund has been applied. It would also be nice to link to the patron in question in the message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 23707] New: Z39.50 import goes to Basic Editor, even when Advanced editor is enabled
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '20

01 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23707 Bug ID: 23707 Summary: Z39.50 import goes to Basic Editor, even when Advanced editor is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hayleymapley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When the EnableAdvancedCatalogingEditor is set to enabled, I expect that Z39.50 import in the Cataloguing module would take you into the Advanced Editor, as the Advanced Editor and New record buttons do. Here is what I think is expected: https://koha-community.org/manual/19.05/en/html/cataloging.html#advanced-ed… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 24862] New: REST API throws 500 errors for browser after logout
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '20

30 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24862 Bug ID: 24862 Summary: REST API throws 500 errors for browser after logout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au It looks like the REST API might not be handling cookies correctly. To test: 0. Use koha-testing-docker 1. Login to http://localhost:8080/ 2. Go to http://localhost:8080/api/v1/libraries 3. Observe a 200 OK HTTP code and JSON output 4. Logout from http://localhost:8080/ 5. Go to http://localhost:8080/api/v1/libraries 6. Observe a 500 Internal Server Error and the following JSON output: {"error":"Something went wrong, check the logs."} It seems to me that really that should be returning a 401 and the following JSON output: {"error":"Authentication failure."} -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 22167] New: Allow itemnumber column to be labelled differently when using bach item edit feature
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '20

30 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22167 Bug ID: 22167 Summary: Allow itemnumber column to be labelled differently when using bach item edit feature Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 19233 added a feature that allows you to send a list of items to the item batch edit from a saved SQL report. At the moment this only works, if your column is displayed as itemnumber. Example: Works: show itemnumber from items; Doesn't work: show itemnumber as "Item#" from items; This is not nice for translations. It would be nice if there was a different way to mark the itemnumber and explicitly activate the feature. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 22434] New: correct item callnumber search link
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '20

30 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22434 Bug ID: 22434 Summary: correct item callnumber search link Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Many places show item callnumber as a link to a search on this callnumber. The correct way is : (opac-)search.pl?q=callnum:%22[% callnumber | uri %]%22 I propose an include that creates think search link. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 22522] New: ILL API breaks with updated Mojolicious version
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '20

30 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22522 Bug ID: 22522 Summary: ILL API breaks with updated Mojolicious version Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: jose-mario.monteiro-santos(a)inlibro.com CC: andrew.isherwood(a)ptfs-europe.com, philippe.blouin(a)inlibro.com Target Milestone: --- When we tried to setup the ILL module using FreeForm as its backend, the ILL requests page in our staff client would not load any of the requests. We would get an error message saying that there was a problem with missing content in the Datable. Upon investigation, we discovered that the calls made to the API were returning "Malformed query" errors. When validating the query, Auth.pm checks for authorized parameters in openapi.op_spec, which wasn't defined anywhere in our case. After a quick discussion with Andrew Isherwood on IRC, we downgraded Mojolicious (from 8.02 to 7.21), JSON::Validator (from 3.02 to 0.97) and Mojolicious::Plugin::OpenAPI (from 2.08 to 1.15) and everything worked. Isn't this problematic ? If these modules aren't installed or don't meet the minimum version required by Koha, cpan will install the most recent versions and the API won't work. While this was experienced with the ILL module, I assume that other API calls can and will break in the same way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 24964] New: Remove pagination when searching for patrons with permissions
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '20

29 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24964 Bug ID: 24964 Summary: Remove pagination when searching for patrons with permissions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Depends on: 12648 There are several places where we are searching for patrons with given permissions, like adding a user to a fund, basket or suggestion (from bug 23590). >From svc/members/search: 88 # It is not recommanded to use the has_permission param if you use the pagination 89 # The filter is done AFTER requested the data See also bug 12648. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12648 [Bug 12648] Link patrons to an order -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 20194] New: Display items.ccode as well as both biblioitems.itemtype and items.itype in circulation screens
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '20

29 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20194 Bug ID: 20194 Summary: Display items.ccode as well as both biblioitems.itemtype and items.itype in circulation screens 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: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment in circulation screens only one "item type" is displayed, biblioitems.itemtype or items.itype, depending on the item-level_itypes system preference. It is however possible for libraries to use both, biblioitems.itemtype to qualify the record, and items.itype to qualify the item itself. In such a scenario only one of the two will be displayed on the circulation screen. It is also possible for libraries to use items.ccode to further refine the description of their items, but this information is not displayed on circulation screens. This enhancement will make all this information more visible in circulation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34