October 2018 - Koha-bugs - lists.koha-community.org

[Bug 15032] [Plack] Scripts that fork (like stage-marc-import.pl) don't work as expected
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '18

25 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 --- Comment #31 from David Cook <dcook(a)prosentient.com.au> --- Actually, when working on #10662, I thought about creating a standalone "import daemon", as importing records into Koha is the hardest part of OAI-PMH harvesting. (I already have an extremely fast download worker, but the bottleneck is importing into Koha *sadface*.) For #15032, "Stage MARC records for import" could simply be a script that allows a use to upload MARC records from their browser client to the Koha server, and to pass on some configuration options to accompany those records. We could store all of that on the file system, in the database, or wherever makes the most sense. If we wanted to have fun, we could leave them in-memory and let an import daemon suck them out of memory instead of a disk which would require way more I/O ops. Once the records are uploaded to the Koha server and stored <wherever> with the job details, the PSGI/CGI script alerts the "import daemon" that it would like to start the job. Now the "import daemon" should probably have a master listener process which does very little work, which makes it highly responsive to queries from the Koha web client. That master listener process can talk to worker processes that do the actual work. In terms of imports, it probably would be good if the master process can query the workers for progress updates (and probably also allow cancellations of imports - which might be useful for very large imports). (Oh another thing... this import daemon wouldn't just be usable from a web interface. It could also be used by command line tools. Thus we have 1 point for getting records into Koha, and that daemon can act as gatekeeper.) We default the "import daemon" workers to maybe 1 worker, but allow it to be configurable, so that large Koha instances can commit more resources to it. (If we were smart, we'd probably have the import daemon use TCP for communications and allow workers to be distributed. Although to do that we'd need to package Koha libraries for working with records and distribute those too. Plus we'd need database configuration information distributed. I mean we could have an API to handle all the actual imports, but that would be slow...) Just some ideas ^_^. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15032] [Plack] Scripts that fork (like stage-marc-import.pl) don't work as expected
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '18

25 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 --- Comment #30 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jonathan Druart from comment #26) > I do not think your Koha::Daemon will work for the background jobs. > > To me, the best way to fix this would be to provide a Koha daemon, instead. > But it would watch a DB table, which would allow us to build a view on top > of it to manage the different jobs (and history). > > We could also have different daemons for different needs (a param of the > daemon matching a column in the DB table). > > The question behind that is security, we will have to list the different > operations the daemon is allowed to process (and so we will loose > flexibility). > > I have spent a *lot* of time trying to fix this issue by forking, etc. And > my conclusion is: it's not feasible (see discussions and tries on related > bug reports) > > See also bug 1993. My Koha::Daemon is just a module for making a daemon process; it's similar to Proc::Daemon on CPAN. But yeah I could see my Koha::OAI::Harvester::Listener and Koha::OAI::Harvester not working for all background jobs. They work well in my case but I'd be happy to actually replace (elements of) them with a more general Koha solution, if it worked for my use case too. Yeah I think that different daemons for different needs makes sense too. Like in the case of #10662, I originally wrote a generic job server, but then realized it might not suit everyone, so I re-wrote it just for that specific task of harvesting OAI-PMH records. Yeah, I don't think forking makes sense in a Plack/persistent environment. Actually, I don't think it makes sense in the CGI environment either, but it "worked". Setting up separate daemons is easy. I don't know why we don't just do that. The issue then I suppose is security, as you've said, and deciding on communication protocols. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15032] [Plack] Scripts that fork (like stage-marc-import.pl) don't work as expected
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '18

25 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 --- Comment #29 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jonathan Druart from comment #27) > My idea would be "something that works", I have already tons of things that > do not work. I am not sure letting other developer retrying again what did > not work is a good idea :) > Let's discuss and agree on an idea, then I can implement it. That works for me too! So long as we have some sort of timeline/deadline I think, so that we don't let the discussion go on forever? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14048] Change RefundLostItemFeeOnReturn to be branch specific
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '18

25 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14048 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |21654 --- Comment #98 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Jonathan Druart from comment #97) > There is one occurrence left: > C4/Installer.pm: push @fnames, C4::Context->config('intranetdir') . > "/installer/data/mysql/mandatory/refund_lost_item_fee_rules.sql"; > > Please fix! See bug 21654, thanks! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21654 [Bug 21654] Installer is loading a non-existing file -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15486] Restrict number of holds placed by day
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15486 --- Comment #90 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 81087 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81087&action=ed… Bug 15486: Fix failing test in GetHardDueDate.t -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7614] Branch transfer limit and holds
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7614 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexbuckley(a)catalyst.net.nz Status|Needs Signoff |Patch doesn't apply --- Comment #26 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Sorry the patches do not apply, can you please rebase: Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 7614: Add a new method Koha::Libraries->pickup_locations Using index info to reconstruct a base tree... M t/db_dependent/Koha/Libraries.t Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Koha/Libraries.t CONFLICT (content): Merge conflict in t/db_dependent/Koha/Libraries.t Failed to merge in the changes. Patch failed at 0001 Bug 7614: Add a new method Koha::Libraries->pickup_locations The copy of the patch that failed is found in: /home/vagrant/kohaclone/.git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-7614-Add-a-new-method-KohaLibraries-pickuploca-2UIRVc.patch You have new mail in /var/mail/vagrant -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21068] New: NorwegianPatronDBEnable - Check for prior ModMember calls that passed 'sync'
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21068 Bug ID: 21068 Summary: NorwegianPatronDBEnable - Check for prior ModMember calls that passed 'sync' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When QAing Bug 20287 the one thing I wasn't 100% sure about was line 289 which we have marked with a FIXME. I could not find anywhere in koha that passed in a sync key to ModMember and as such we believe it was safe to remove it. This bug serves as a note to get Magnus to double check our assumptions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 15486] Restrict number of holds placed by day
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15486 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #89 from Nick Clemens <nick(a)bywatersolutions.com> --- Awesome work all! Pushed to master for 18.11 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for opac and intranet
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #4 from SysAdmin <systems(a)decatur.lib.al.us> --- Since Koha has added a timeout function to the Self check and Self return systems, which seem to work on the Opac side (not the intranet side) shouldn't this be an easy enhancement/bug to fix now? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16858] New: import_borrowers.pl does not load because of mysql 5.7
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16858 Bug ID: 16858 Summary: import_borrowers.pl does not load because of mysql 5.7 Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: npm(a)zefanjas.de QA Contact: testopia(a)bugs.koha-community.org The Import Patrons tool does not load on MySQL 5.7 because of the default sql_mode: only_full_group_by. This is the error I got: http://paste.koha-community.org/16 Can't use an undefined value as an ARRAY reference at /usr/lib/x86_64-linux-gnu/perl5/5.22/DBI.pm line 2083 If I change the sql_mode to a mysql 5.6 behavior the import page loads fine. -- You are receiving this mail because: You are watching all bug changes.

1 4