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

[Bug 26856] New: Asw
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26856 Bug ID: 26856 Summary: Asw Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Browser compatibility Assignee: oleonard(a)myacpl.org Reporter: ersonaggrn04(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 112660 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=112660&action=e… Pkkkk Kontolll -- You are receiving this mail because: You are watching all bug changes.

1 1

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

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 --- Comment #43 from David Cook <dcook(a)prosentient.com.au> --- See Bug 26854 for a potential fix. While I haven't tried with Plack, we haven't been forking stage-marc-import.pl correctly in a CGI environment either. -- 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 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26854 -- You are receiving this mail because: You are watching all bug changes.

1 0

[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

[Bug 14784] Missing checkin message for debarred patrons when issuing rules 'fine days = 0'
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '20

29 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14784 --- Comment #54 from Arthur Suzuki <arthur.suzuki(a)biblibre.com> --- Hi Alexis, Sorry for the late reply... After applying both patches I still get a failed tests: <pre> root@kohadevbox:koha(master)$ prove t/db_dependent/Circulation.t t/db_dependent/Circulation.t .. 27/50 # Failed test 'AddReturn must have debarred the patron' # at t/db_dependent/Circulation.t line 89. # got: '' # expected: '1' # AddReturn returned message $VAR1 = { # 'WasReturned' => 1 # }; # Looks like you failed 1 test of 29. t/db_dependent/Circulation.t .. 29/50 # Failed test 'AddReturn + suspension_chargeperiod' # at t/db_dependent/Circulation.t line 2397. t/db_dependent/Circulation.t .. 48/50 # Looks like you failed 1 test of 50. t/db_dependent/Circulation.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/50 subtests Test Summary Report ------------------- t/db_dependent/Circulation.t (Wstat: 256 Tests: 50 Failed: 1) Failed test: 29 Non-zero exit status: 1 Files=1, Tests=50, 22 wallclock secs ( 0.07 usr 0.01 sys + 17.66 cusr 1.62 csys = 19.36 CPU) Result: FAIL </pre> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26850] New: Turning off pick up location does not affect current hold request
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26850 Bug ID: 26850 Summary: Turning off pick up location does not affect current hold request Change sponsored?: --- Product: Koha Version: master 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 Each year, schools or other libraries that have to close for a season can have their pick up locations turned off. However, this does not affect currently active hold requests that chose that library as a pick up location. I would suggest a feature either in preferences or in the individual library next to the pick up location switch that would, if enabled, suspend that hold when triggered, flag the hold as needing attention, and notify the patron that the hold has been suspended until they choose a new pick up location. This could either be invisible to the staff, and the check-in would then go to the next patron in the queue, or it could alert the staff member at check in and give them the option to trigger the next hold or ignore (I think the first option would be less staff intensive). The patron's hold list could list the item as suspended, and needs attention. Once they choose a new location, it would unsuspend, and they would not loose their place in the queue. Or they could choose to ignore, and wait for the location to open, which would reactivate the hold (based on the needing attention flag), or they could choose to cancel the hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 25665] New: test t/db_dependent/Circulation.t fails on a specific date
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25665 Bug ID: 25665 Summary: test t/db_dependent/Circulation.t fails on a specific date Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org 2020-06-02 == Test plan == Warning: changing the system time to something too far in the past will disrupt HTTPS & TLS so you will have errors if you try to browse the web in parallel. And other software(like email clients) might pop errors. Nothing to worry about. 1. Set system date to 2020-06-01 (time: somewhere during that day) 2. prove t/db_dependent/Circulation.t 3. "All tests successful." 4. Set system date to 2020-06-02 (time: somewhere during that day) 5. prove t/db_dependent/Circulation.t 6. Fail 7. Set system date to 2020-06-03 (time: somewhere during that day) 8. "All tests successful." master : doesn't happen 19.11.x: doesn't happen 19.05.x: happens (v19.05.11) -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 26434] New: Plugin dirs duplicates in @INC with plack
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26434 Bug ID: 26434 Summary: Plugin dirs duplicates in @INC with plack Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Plugin dirs defined in koha-conf.xml are added to @INC in order to compile perl code. Looks like with plack those dirs are added several times. This may lead to an error "INCLUDE_PATH exceeds 64 directories". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 --- Comment #24 from Agustín Moyano <agustinmoyano(a)theke.io> --- Ok, Séverine, just removed all Data::Printer from code. Could you please try again? Thanks -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '20

28 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 --- Comment #23 from Agustín Moyano <agustinmoyano(a)theke.io> --- Created attachment 112646 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=112646&action=e… Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t -- You are receiving this mail because: You are watching all bug changes.

1 0