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

[Bug 25694] New: Add ability to delete a Marc Modification Template when viewing
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '20

02 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25694 Bug ID: 25694 Summary: Add ability to delete a Marc Modification Template when viewing Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, the ability to delete a Template in Marc Modification templates only exists from the marc_modification_templates.pl, however, it would be nice to have the ability to delete the template, when you are looking at the actions of that template. If you accidentally make two templates of the same name and want to delete one, it is hard to be sure which one you are deleting from the list of the templates without seeing the actions of each one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 25845] New: Cannot limit system logs to 'api' interface
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '20

02 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25845 Bug ID: 25845 Summary: Cannot limit system logs to 'api' interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 22600 added the 'api' interface to the system, we should also add this as a limit in the tools -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 26086] New: Add a 'cron' interface limit to the log viewer
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '20

02 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26086 Bug ID: 26086 Summary: Add a 'cron' interface limit to the log viewer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org bug 22600 added interfaces for 'api' and 'cron bug 25845 add a limiter for 'api' to the tool viewer let's add the 'cron' one too -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 22106] New: Column settings needs to include OPAC and Intranet holds (requests) tables
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '20

30 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22106 Bug ID: 22106 Summary: Column settings needs to include OPAC and Intranet holds (requests) tables Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- The hold request tables need to be included in the Column settings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20342] New: Fix table locking issue, progress bar not updating, and allow use of plack for Stage MARC Import
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '20

30 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20342 Bug ID: 20342 Summary: Fix table locking issue, progress bar not updating, and allow use of plack for Stage MARC Import 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Have you ever seen this error? DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction [for Statement "INSERT INTO import_record_matches (import_record_id, candidate_match_id, score), Have you ever noticed your progress bar during stage for import jumps from 0% to 100% with no updates in between? Would you like stage-marc-import.pl to work under plack? If you answered yes to any of the following questions, this bug is for you! During uploads of large records using matching rules, we were getting 'Failed to submit form' popups on the marc record importer. First, I noticed that the parent process of stage-marc-import.pl wasn't returning the job id via ajax until the child process had completed. This works fine for smaller files as they process fast. For large files ( and in particular when using matching rules ) the process takes *much* longer. It appears that $.ajax will resubmit the form if it doesn't get a response back in a given time ( I would estimate that to be about 30 seconds or so ). This causes a *second* instance of stage-marc-import.pl to be run. So now we have two processes both running transactions on the same table for the same batch id. I believe this is what is causing the Deadlock. So, the crux of the matter is that for whatever reason, the parent process will not output until the child process has gone away. Hours of research entailed. The final answer is that the child process must be detached from the parent process. I tried doing this via setsid() but it did not help. Finally, I found that using Net::Server::Daemonize did! After I had my solution, I decided to see if stage-marc-import.pl and background-job-progress.pl could now be run under plack, and it appears that they can! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 25913] New: Internal server error when calling get_coins on record with no title (245) but with 880 linked to 245
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25913 Bug ID: 25913 Summary: Internal server error when calling get_coins on record with no title (245) but with 880 linked to 245 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In opac search results we call get_coins in an eval so it can load, on other scripts we don't The get_coins routine calls: $title = $record->field('245')->as_string('ab'); With no check that the 245 exists. Simple fix would be to call get_coins in an eval everywhere More comprehensive would be to fall back to 880 field linked ot 245, and then fallback to blank This only affects MARC21 I believe as the UNIMARC implementation gets the field directly without as_string To recreate: 1 - Load attached record or create a record with 880 and no 245 2 - Enable COinSinOpac 3 - Search for record in staff or opac, it loads in results 4 - Add item to a public list, cannot view in opac 5 - Try to view ISBD or MARC tab on staff client, it fails When indexing in ES we convert an 880 to its linked field so the record is searchable, so we could make that a sbroutine -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 26260] New: elasticsearch>cnx_pool missing in koha-conf-site.xml.in
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26260 Bug ID: 26260 Summary: elasticsearch>cnx_pool missing in koha-conf-site.xml.in Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 22705 Added by bug 22705, but only in etc/koha-conf.xml Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22705 [Bug 22705] Change default value of Elasticsearch cxn_pool to 'Static' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 24780] New: 952$i stocknumber does not display in batch item modification
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24780 Bug ID: 24780 Summary: 952$i stocknumber does not display in batch item modification Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When trying to edit items via batch item modification, the subfield i does not display. To recreate, add a value to 952$i, then add that barcode to the batch item modification function. You will see the value display in the item summary across the top of the screen, but the $i does not show in the edit section below. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 26224] New: Prevent double submit of header checkin form
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26224 Bug ID: 26224 Summary: Prevent double submit of header checkin form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Same as bug 26136, but for the checkin form in the header -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 25810] New: Stage MARC records for import progress meter sticks at 0%
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25810 Bug ID: 25810 Summary: Stage MARC records for import progress meter sticks at 0% Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: Boze.1(a)nd.edu QA Contact: testopia(a)bugs.koha-community.org Created attachment 106031 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106031&action=e… Gateway time-out error during staging records This is somewhat similar to bug 1816 and bug 18719. We are using Koha 18.11 and upgrading to 19.11, and experience it in both versions. We are importing large sets of biblios on a quarterly basis, around 70,000 records broken into files of 10,000. In the "Stage MARC for import" tool, after clicking the "Stage for import" button, the progress meter sticks at 0%. After about 90 seconds a popover message displays with a "504 Gateway Timeout" and an error saying that the import of records failed. The page doesn't update further, although after waiting a sufficiently long period of time, the "Staged MARC management" tool shows that the records have been staged. We are using nginx as a load balancer, which is what I suspect causes the gateway timeout error. If the progress meter were receiving data to update it, this would probably prevent the timeout and the page would finish uninterrupted. I'm attaching an image of the error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2