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

[Bug 7947] 440/490 Koha Mapping
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7947 --- Comment #47 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Nice work everyone! Pushed to master for 20.05 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7947] 440/490 Koha Mapping
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7947 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |20.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23290] XSLT system preferences allow administrators to exploit XML and XSLT vulnerabilities
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23290 didier <didier.gautheron(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |25373 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25373 [Bug 25373] Bug 23290 Security fix break all XSLT entities -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25302] New: The indentations should be in accordance with the Coding guidelines.
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25302 Bug ID: 25302 Summary: The indentations should be in accordance with the Coding guidelines. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: timothy_alexis.vass(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org Simply put, the indentations are inconsistent. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 25304] New: Some of the mark needs to be corrected
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25304 Bug ID: 25304 Summary: Some of the mark needs to be corrected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: timothy_alexis.vass(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 --- Comment #219 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #218) > Why would you need to replace a null byte with a semicolon (;)? > > It seems to me that email addresses should be separated by a comma? Actually, looking at https://metacpan.org/release/Mail-Sendmail/source/lib/Mail/Sendmail.pm#L334, it seems that Mail::Sendmail doesn't care about separators. It just iterates through a string looking for valid email addresses... yikes... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 --- Comment #218 from David Cook <dcook(a)prosentient.com.au> --- Comment on attachment 68560 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=68560 Bug 7317: Interlibrary loans framework for Koha. Review of attachment 68560: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=731…) ----------------------------------------------------------------- ::: Koha/Illrequest.pm @@ +838,5 @@ > + } elsif ( 'draft' eq $params->{stage} ) { > + # Create the to header > + my $to = $params->{partners}; > + $to =~ s/^\x00//; # Strip leading NULLs > + $to =~ s/\x00/; /; # Replace others with '; ' Why would you need to replace a null byte with a semicolon (;)? It seems to me that email addresses should be separated by a comma? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25365] New: JavaScript error on neworderempty.pl: $.timepicker is undefined
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25365 Bug ID: 25365 Summary: JavaScript error on neworderempty.pl: $.timepicker is undefined Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 25133 There is a JavaScript error on neworderempty.pl which shows up in the console: $.timepicker is undefined git blame points to Bug 25133, "Fix time part of due date for 12hr" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25133 [Bug 25133] Specify Due date changes from PM to AM if library has their TimeFormat set to 12hr -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 1993] Task Scheduler Needs Re-write
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993 --- Comment #53 from David Cook <dcook(a)prosentient.com.au> --- At the moment, I'm writing a new task scheduler in Golang for a plugin version of Bug 10662. Like the existing Perl version attached to Bug 10662, it closely couples the task scheduler and OAI-PMH harvester. In the Golang case, when the timer fires, a new thread is created to do a HTTP download of XML (which actually pipes the XML stream into another thread with a XML stream reader in it which concurrently parses and writes away the downloaded records). I am planning to give each task a thread to take those downloaded records and import them into Koha (via a Plugin API). But if I were to use a more generalized task scheduler... I'm not sure how I'd do it. If we did have a message queue, perhaps the download task would send the records to an API which would record them and then enqueue a RabbitMQ message to an import worker. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 1993] Task Scheduler Needs Re-write
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993 --- Comment #52 from David Cook <dcook(a)prosentient.com.au> --- I've been thinking more about this recently. How to be all things to all people? For instance, the original Koha task scheduler for Bug 1993 was meant to schedule a report to run once at an absolute time and email the result to someone. Bug 25245 wants plugins to be able to run every night. That is, a periodic task that runs at the same time every day/night (while not being too fussed on exact start/end times). Bug 10662 wants to schedule tasks to run every X seconds. That is, a periodic task that runs X seconds after it last ran. Those are arguably 3 different types of schedules. The Celery project would handle that using ETA and Periodic Tasks: https://docs.celeryproject.org/en/stable/userguide/calling.html#eta-and-cou… https://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html Looking at cron, we can see it just loops infinitely and sleeps for 1 minute at a time then checks what jobs need to run: https://github.com/cronie-crond/cronie/blob/master/src/cron.c#L358 In the past, I've used timers using Perl's POE or Golang's Timer to alert me when a job needs to start. That's fine so long as your process runs forever. You do need to persist the job data, so that if you restart you can re-create your timers. In terms of the actual implementation... lately I'm thinking a daemon with a HTTP API so you can create, retrieve, update, delete, start timer, stop timer. When a timer does fire... the daemon should add the task to a queue. (This is also what cron does https://github.com/cronie-crond/cronie/blob/master/src/cron.c#L589) Now that queue could be a RabbitMQ message queue. It could be an in-memory queue in the task scheduler daemon and it could run tasks itself by forking a child process, using a thread (if not Perl), or using a connected worker. It could be a database table. On that note, it becomes apparent to me that we don't need to depend on Bug 22417 to move forward here. The task scheduler can be a black box with an API for the front end, and then pluggable backends for different queue systems. Although as I say that I haven't thought it through enough. With a FIFO queue, we run into cron's limitation of not tracking execution of a task. As is, Bug 10662 scenario is impossible, because we don't have the result of the task to update the task with new data (ie new "from" date) and new time to schedule. With RabbitMQ, we can use message acknowledgements to determine when the task is completed. Celery also has a result store. But Bug 10662 would still be unique in that it's not really a periodic task but rather an absolute task that gets rescheduled. It looks like Celery does actually have callbacks that can be run on the result at the end of a task. That's interesting. That would be a good thing to develop. Arguably the Report Email functionality could make good use of that. The task would be to generate the report and store the result. The callback would then email it. In the case of Bug 10662, the callback could perhaps update the original task, enqueue a new one. I'd have to think more about that mechanism... -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0