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

[Bug 25195] New: login button is not working.
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25195 Bug ID: 25195 Summary: login button is not working. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: gouravchawda.240(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org when user enter the credential and click login button to login the account the login button is not clickable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 25194] New: Whwh
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25194 Bug ID: 25194 Summary: Whwh Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: armymrcyber(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 103227 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103227&action=e… Happy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23563] New: login button not working
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23563 Bug ID: 23563 Summary: login button not working Change sponsored?: Sponsored Product: Koha Version: 17.05 Hardware: PC OS: Windows Status: NEW Severity: major Priority: P5 - low Component: Browser compatibility Assignee: oleonard(a)myacpl.org Reporter: konenianitha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: konenianitha(a)gmail.com 1.given correct credentials 2.click the login button 3. not opening my account -- You are receiving this mail because: You are watching all bug changes.

1 4

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

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #291 from David Cook <dcook(a)prosentient.com.au> --- On one hand, I feel like we're so close with the current patches. It just needs more unit tests. On the other hand, the unit tests for the task scheduling and concurrent processing are actually quite challenging. Also, these patches are a huge chunk of functionality, which increase Koha's overall size. I am tempted to take this code and split it into two parts: 1. Koha plugin for Web functionality 2. Standalone OAI-PMH harvester My thinking is the Koha plugin will allow you to connect to a separately packaged OAI-PMH Harvester API in order to add/start/stop/update/remove harvesting tasks. Easy! The standalone OAI-PMH harvester will then take care of the scheduling of tasks and high-performance downloading of records. The OAI-PMH harvester will then have actions to take on downloaded record batches. Not too hard! This is where things get interesting. Ideally, there would be a Koha API backed by a queue and Koha worker(s) to handle the processing of records. But that doesn't currently exist. I can use the Koha plugin to inject an API route, but there is no existing queue mechanism. Uh oh! The API could be used to store the records in a database table, but then I would need a Koha-based worker to access that database table and apply all the Koha-specific rules to the data. At this point it would be nice to have RabbitMQ for the queue, and then the Koha plugin could provide a Koha worker I suppose, which a sysadmin could manually start. I suppose we don't have to have RabbitMQ. The Koha worker could just tap into the database directly (until RabbitMQ is available). So in the end I suppose really 3 parts: 1. Koha plugin (Web functionality) 2. Koha plugin (Import Worker functionality) 3. Standalone OAI-PMH harvester Alternatively, the import API could handle all the Koha-related processing. I could do some tests to see how fast the web API could process the data. The OAI-PMH download will probably always be faster than the upload, so the OAI-PMH harvester would need to have its own internal queue for the downloaded records, but that could keep the Koha side of things slimmer. Plus... if Koha did implement a message queue like RabbitMQ, that change could be done transparently in the Koha background without affecting the OAI-PMH harvester. Ok so... 1. Koha plugin (Web UI to interact with OAI-PMH harvester) 2. Koha plugin (Import API to receive harvested OAI-PMH records) 3. Standalone OAI-PMH harvester I think that this makes sense. People could use the plugin, and then if they're liking it, then we could try again to get it into Koha master. I am actually interested in rewriting the OAI-PMH harvester in Golang to take advantage of its concurrent programming strengths. By using the Koha plugin to provide/consume APIs, we're able to use the best tools for the job for the actual OAI-PMH work. Note too that the OAI-PMH harvesting itself isn't actually Koha-specific. The only Koha-specific aspects are the scheduling and the record import. There's no real need to have the OAI-PMH code in the Koha codebase. -- You are receiving this mail because: You are watching all bug changes.

1 0

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

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #290 from David Cook <dcook(a)prosentient.com.au> --- I've looked more at Bug 22417, and it's got me thinking. The OAI-PMH harvester has a few core needs: 1. Instant communication between Web UI and OAI-PMH harvester to coordinate harvesting tasks 2. Ability to schedule tasks 3. Ability to execute and repeat download tasks in parallel in the background 4. Ability to save downloaded records 5. Ability to import records into Koha The first is achieved by exchanging JSON messages over a Unix socket. (I'd actually like to change this to a TCP socket and use JSON messages over a HTTP API. Using HTTP would make it easier to communicate over a network, simplify the client code using standard communications mechanisms, and has authentication methods which could help to secure the OAI-PMH harvester. I could also provide a Docker image that contains the OAI-PMH harvester in a separate Docker container from the Koha application server.) This works fairly well and is easy enough to achieve. The second is provided by a bespoke scheduler using POE timers built into the OAI-PMH harvester. Given the granularity of the scheduling, I don't see this changing any time soon. In theory, a generic Koha task scheduler could replace this functionality, but that seems unlikely any time soon. This is arguably one of the most complex parts of the OAI-PMH harvester. Currently, the OAI-PMH uses an in-memory queue for download tasks, and a database queue for import tasks. I thought a lot about how RabbitMQ might be used to replace these queues. It could be useful to replace the in-memory download queue, and the download workers could be split out of the existing OAI-PMH harvester. As for the import tasks, the download workers need to save the records and enqueue an import task ASAP. At the moment, they save the records to disk, and add an import task to the database with a pointer to the records on disk. It works well enough, but it assumes that you have the disk space, and that the import worker has access to the local disk. I've been thinking it would be better to either 1) save the records to the database and enqueue a RabbitMQ message with a pointer to the database, or 2) send the records in a RabbitMQ message. I think the 1st option is probably better, because there is increased visibility. You can't see all the messages in a RabbitMQ queue. That all said, saving to disk is going to be faster than sending the data over a network. (However, in the past I think that I've sent individual records over the network. In this case, I'd be sending whole batches of records at once.) But for a download worker to send records, it would need credentials for either the database or RabbitMQ... so I'm thinking that perhaps it would be better to use an import API with an API key, although that would involve receiving all the data over the network and then sending it to the database. Also slow. But haven't tested the actual speeds. The import API would save the data to the database, and then enqueue an import task. Of course, this would just be a re-working of what's already here. The benefits of re-working the queues and workers are arguable at this point, although there is certainly benefits of changing from a bespoke client/server communication protocol to HTTP over TCP. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24614] New: Can't edit reports if not using cache
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24614 Bug ID: 24614 Summary: Can't edit reports if not using cache Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: Enable strict mode Disable/stop memcached Create a report (note you don't see the cache expiry option) Try to edit the report It fails Enable memcached You get the cache expiry option back You can edit -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 24760] New: BackgroundJob tests fail with latest versions of YAML or YAML::Syck
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24760 Bug ID: 24760 Summary: BackgroundJob tests fail with latest versions of YAML or YAML::Syck Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org YAML 1.30 and YAML::Syck 1.32 introduce a breaking change : they won't bless loaded objects by default, and t/db_dependent/BackgroundJob.t fail when this feature is disabled. I don't know this module very well, but I think that the tests are broken. C4::BackgroundJob::fetch already bless the object returned from $session->param, so we don't need to test that $session->param returns a blessed object. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 23383] New: IdRef link appears even with syspref is off
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23383 Bug ID: 23383 Summary: IdRef link appears even with syspref is off Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org IdRef link is displayed via XSLT. There is a test of syspref with just if value is defined. But in installer/data/mysql/sysprefs.sql you see this pref will be 0 by default, which is true in XPATH. We should test that pref is 1. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 24851] New: No sample libraries for UNIMARC installations
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24851 Bug ID: 24851 Summary: No sample libraries for UNIMARC installations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org I am trying to make koha-testing-docker UNIMARC compabible. In order to have koha-misc4dev insert all the data correctly (users, etc.) we need at least 1 library. I am suggesting to reuse the usual library list for UNIMARC. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 24518] New: Partner filtering does not work in IE11
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24518 Bug ID: 24518 Summary: Partner filtering does not work in IE11 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com We're doing something like this to hide options that are not applicable to the current filtering string: $('#my_select_option').hide(); This applies the following CSS rule to the <option> element: display: none It turns out that IE won't hide option elements. So, that's annoying. We have a couple of choices here. We could either clone the entire list of partners, filter out the ones that don't match the search string and then use the remainder to repopulate the <option> elements. Or we could wrap the <options> in something that IE11 will apply display:none to, such as a <span> or something. However, this will lead to something that is semantically incorrect for HTML5, since a <select> can only have <option> or <optgroup> as it's children. Despite the first option feeling a bit gnarly, I'm going to go for that as it will fix the problem and not lead to broken markup. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13