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

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 21 May '20

21 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #294 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Michal Denar from comment #293) > I really like this idea. Czech Koha community want to help change this idea > to project. How can we cooperate? If we'll work together, we'll finish this > sooner. I hope. > > Michal That's great to hear, Michal! The thing that I will probably need most is testers. I don't have anything to test yet, but I am hoping to have something soon. Here's the list of components I'll be developing: 1. Koha UI - Koha plugin (Web UI to interact with OAI-PMH harvester HTTP management API) 2. Koha Import API - Koha plugin (Import API to receive harvested OAI-PMH records) 3. Standalone OAI-PMH harvester (Statically compiled Golang daemon with HTTP API for management) Last night, I started work on the "Koha Import API" plugin (https://github.com/minusdavid/koha-plugin-oaipmh-import) My next steps for that are clear, so I just need to sit down and do some work on that. Maybe tomorrow night. I've done experimental work on the "Standalone OAI-PMH harvester", but I haven't posted that to Github yet. I think that I've mostly settled on a scheduler methodology so hoping to make rapid progress on this one too. The plan with this will be to post the source code on Github, but also to provide a compiled binary that people can just download and run. (I might start with a Linux binary, but I've been thinking about doing a Windows binary too.) I may also provide a Docker image for the harvester as well to ease testing and deployment. The "Koha UI" plugin will probably be the last thing I do, since it depends on the HTTP API for the "Standalone OAI-PMH harvester". However, it should be fairly straight forward. Sorry for all the words! Just sharing my current plans! A lot of the work will be modeled off what I did for Bug 10662, but will probably be simpler. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13881] Add ability to defined circulation desks
by bugzilla-daemon＠bugs.koha-community.org 21 May '20

21 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13881 --- Comment #59 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Nicolas Legrand from comment #58) > At first it was doing more but I cut it up into three > after rewrite to help the work for QA. Makes sense to me. > I'm surprised it sounds niche :), I > know not so few libraries with multiple desks and waiting reserves. Truth is > it's even odd for me it wasn't there. What sort of libraries are these? Public libraries? I've worked in academic libraries and special libraries and we always had just 1 circulation desk per library branch, which had all the waiting reserves for that branch behind it. I don't think that I've even used a library (in Canada or Australia) that has had multiple circulation desks? Not that I'm being negative. I'm really intrigued! Very different to my experience, so it's interesting to learn about different setups. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25502] New: /advanced_editor/macros doesn't follow coding guidelines
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25502 Bug ID: 25502 Summary: /advanced_editor/macros doesn't follow coding guidelines 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: tomascohen(a)gmail.com This development started before the changes we introduced in the guidelines in late 2019, and the major code changes that took place in January 2020. - Attribute mapping logic is now on the Koha::Object-level (the patches implement that, but are not using it) - Related to the above, some helper methods like to_api and to_model are kept, the same for the mappings in the controller, they should all go away - Related to the above, set_from_api and new_from_api should be used instead of using helper to_api and to_model methods in the controller - $c->objects->search doesn't use the to_model and to_api params - Response status codes need to be changed, at least for DELETE operations -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 25493] New: Unhandled exceptions cause an exception
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25493 Bug ID: 25493 Summary: Unhandled exceptions cause an exception Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com We rushed into using Koha::Logger as a Mojo::Log implementation, but there are some differences that need to be addressed before that can actually happen. This is not *that* problematic for production sites, but some things like hitting an undefined route will raise weird errors we need to avoid: GET http://kohadev.myDNSname.org:8081/api/v1/hola The application raised the following error: Can't use an undefined value as an ARRAY reference at template mojo/debug.html.ep line 311. 306: %= $kv->(Time => scalar localtime(time)) 307: </table> 308: </div> 309: <div class="tap">tap for more</div> 310: </div> 311: % if (@{app->log->history}) { 312: <div id="log" class="box infobox spaced"> 313: <table> 314: % for my $msg (@{app->log->history}) { 315: <tr> 316: <td class="striped value wide"> and the StackTrace middleware couldn't catch its stack trace, possibly because your application overrides $SIG{__DIE__} by itself, preventing the middleware from working correctly. Remove the offending code or module that does it: known examples are CGI::Carp and Carp::Always. <<<<< We need to move back to using plain Koha::Logger, and rethink the proposal from bug 18205 to use MojoX::Log::Log4perl. That certainly belongs to another bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 25501] New: Wide character in print warning installing translations
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25501 Bug ID: 25501 Summary: Wide character in print warning installing translations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Install any translation, (cd misc/translator/; ./translate install fr-FR ) see example output Wide character in print at /../misc/translator/tmpl_process3.pl line 144. Wide character in printf at /.../misc/translator/tmpl_process3.pl line 141. Wide character in print at /.../misc/translator/tmpl_process3.pl line 134 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 25516] New: Item/pickup_locations wantarray removed, so dies on Perl >=5.24 where "autoderef" feature absent
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25516 Bug ID: 25516 Summary: Item/pickup_locations wantarray removed, so dies on Perl >=5.24 where "autoderef" feature absent Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: stalkernoid(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, slavashishkin(a)gmail.com After last updates, until around May 11, "wantarray" in sub pickup_locations was removed, but it might be hidden on Perls before v5.24, because there was autoderef experimental feature (https://www.effectiveperlprogramming.com/2010/11/use-array-references-with-…) the feature removed in Perl v5.24, and Ubuntu 16.04 has Perl v5.22, Ubuntu 18.04 has Perl v5.26. Since newer Perls it will definitely produce the error because now it uses $arr_reference as a single item and maps over it once, and the process dies with "no method" or whatever. There might be other places in the code that uses this v5.14-5.24 feature for example to keys, map, grep $arr_reference. The place I bumped in: 1. On the clean devenv after “reset_all” go to /cgi-bin/koha/admin/smart-rules.pl and press “Save” button on “Default checkout, hold and return policy” to save the empty record (GUI allows that), – this is needed to have in the table “circulation_rule” key “hold_fulfillment_policy” appeared with empty string value so code will reach the right place. Another option to have the same “hold_fulfillment_policy” empty string is to reset DB and go through onboarding.pl (and how I found). So, after onboarding, you don’t ever need to save the empty record, it will be filled automatically. To check: SELECT rule_name, rule_value FROM circulation_rules WHERE rule_name='hold_fulfillment_policy' it produces: "hold_fulfillment_policy", "" 2. open item record /cgi-bin/koha/reserve/request.pl?biblionumber=1&borrowernumber=1 - it produced the bug: Software error: Can't call method "unblessed" on unblessed reference at ../reserve/request.pl line 581. The code from request.pl line 581: ``` $item->{pickup_locations} = join( ', ', map { $_->unblessed->{branchname} } Koha::Items->find($itemnumber) ->pickup_locations( { patron => $patron } ) ); $item->{pickup_locations_code} = join( ',', map { $_->unblessed->{branchcode} } Koha::Items->find($itemnumber) ->pickup_locations( { patron => $patron } ) ); ``` and that's because sub pickup_locations (recent changes, where wantarray removed, so might be more places) now does this: return \@pickup_locations; Yet it might work on Perl <5.24. Peter: please search through code where we might have similar issues, and meanwhile, provide a patch for the current one above. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #293 from Michal Denar <black23(a)gmail.com> --- I really like this idea. Czech Koha community want to help change this idea to project. How can we cooperate? If we'll work together, we'll finish this sooner. I hope. Michal -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24331] New: Internal server error when placing hold on item if itemtype undefined
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24331 Bug ID: 24331 Summary: Internal server error when placing hold on item if itemtype undefined Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Error is: Can't call method "notforloan" on an undefined value at /usr/share/koha/lib/C4/Reserves.pm line 1199. C4::Reserves::IsAvailableForItemLevelRequest: 1198 my $itemtype = $item->effective_itemtype; 1199 my $notforloan_per_itemtype = Koha::ItemTypes->find($itemtype)->notforloan; We should check that we found an itemtype before calling notforloan -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 25483] New: Url item field no longer accepts html tag
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 Bug ID: 25483 Summary: Url item field no longer accepts html tag Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 104838 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104838&action=e… 1805 url item opac view Hi, In 19.05.04, url item field no longer accepts html tag. Currently, this is not displaying correctly. Like bug #23194? Tested on 18.05 and it was correct. Normal behavior of 19.05 ? Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 15352] Use URLLinkText instead of URL for item links
by bugzilla-daemon＠bugs.koha-community.org 20 May '20

20 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15352 --- Comment #29 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- *** Bug 25483 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0