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

[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 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 25037] New: Add support for multiple checkout types
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25037 Bug ID: 25037 Summary: Add support for multiple checkout types Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is a blocker to Bug 24101. As of now we have two checkout types, a normal checkout and an on-site checkout type. In order to target circulation rules to a specific checkout type, the issues table must have information on which type of checkout it is. On-site checkout is currently determined by a boolean value in issues.onsite_checkout database column. For supporting multiple checkout types, we should convert this column into a generic checkout_type field. This Bug also sets an easy-to-extend base for further checkout types. In theory a library could define any types of checkouts dynamically, but support for that is outside the scope of this Bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 79

[Bug 25089] New: Add checkout_type to circulation rules
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25089 Bug ID: 25089 Summary: Add checkout_type to circulation rules Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is a follow-up to Bug 25037. In that Bug we enabled issues to contain data on its checkout type. In this Bug we will add support for defining circulation rules for those types. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 88

[Bug 18958] New: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958 Bug ID: 18958 Summary: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Imagine you have a record with 3 items, each item is held by LibraryA, LibraryB and LibraryC respectively. Now, a patron places to record level holds for pickup at LibraryD. When any of the items are checked in, that item is trapped to fill the first hold, but a side affect is that the next open hold because item level for the item that was just checked in! This is clearly incorrect and prevents the patron from placing more record level holds on the record. To reproduce: 1. Create and use a patron that can place multiple record level holds per record 2. Create a record with X items, each at a different library 3. Place X 'Next available' holds on the record for the patron using the 'Holds to place' box 4. Check in LibraryA's copy as LibraryA and confirm the hold 5. Revisit request.pl for the record, notice the next hold in line is now item-specific 6. Attempt to place another hold for your patron, notice that it requires an item-specific hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 119

[Bug 23212] New: Patron request modifications enhancement
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23212 Bug ID: 23212 Summary: Patron request modifications enhancement Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Target Milestone: --- Currently patron request modifications are an all or none request. Sometimes requests are entered with mistakes. Sometimes patrons are requesting some changes that are questionable, like a complete name change, or removing a birth date. I would like to suggest that each line of request have an approve, deny, or follow-up radio box. If follow-up is chosen, staff have the ability to add a question, and the question is posed to the patron when they log in to the OPAC. Maybe an e-mail notification of the question, if they have e-mail. Once they answer that question, that particular line request is submitted again with the staff question and patron answer. I would also like to suggest that the new value be editable, so if staff need to format something, or fix an obvious mistake, they can. Right now, if we see something like this, we have to click on the patron link to open the account, accept the changes, refresh the patron page, and fix the mistake. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 22834] New: Add a method for plugins to return the absolute path for bundled files
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22834 Bug ID: 22834 Summary: Add a method for plugins to return the absolute path for bundled files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Plugins::Base inherits from Module::Bundled::Files, which is handy to pack assets together and have a simple way to calculate the asset's path. It would help developing new features to have a way to retrieve the absolute path. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 23796] New: Convert OpacCustomSearch system preference to news block
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '20

24 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23796 Bug ID: 23796 Summary: Convert OpacCustomSearch system preference to news block Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 22318 Building on 22318, the OpacCustomSearch system preference should be converted to a Koha news block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22318 [Bug 22318] Extend Koha news feature to include other content areas -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 22988] New: Visible reduction in image quality
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '20

23 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22988 Bug ID: 22988 Summary: Visible reduction in image quality Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I have a library that is noticing a visible reduction in image and thumbnail quality after upgrading from 18.11.03 to 18.11.05. This could be a regression from bug 21987. They have a lot of scanned black and white covers. The largest text in the thumbnails used to be readable, but after the upgrade, it is not. Their scanning process has not changed, so the original image that they upload should be of the same quality as before. Old, good image: http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagen… http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagen… New, not so good, image: http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagen… http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagen… Did we reduce the quality a bit too much? -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 22612] New: opac-auth.tt should contain OpacLoginInstructions
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '20

23 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22612 Bug ID: 22612 Summary: opac-auth.tt should contain OpacLoginInstructions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Good morning I think that opac-auth.tt should also include [% IF Koha.Preference( 'OpacLoginInstructions' ) %] <div id="nologininstructions-main" class="nologininstructions"> [% Koha.Preference( 'OpacLoginInstructions' ) %] </div> [% END %] This add login instrucctions, it appears for example in opac-main.tt or masthed.inc but on opac-auth.tt there is no login instructions -- You are receiving this mail because: You are watching all bug changes.

1 2