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

[Bug 27007] New: GetMarcSubfieldStructure called with "unsafe" in tests
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27007 Bug ID: 27007 Summary: GetMarcSubfieldStructure called with "unsafe" in tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 23807 It does not feel correct to call GetMarcSubfieldStructure with the unsafe flag set in tests: my $mss = C4::Biblio::GetMarcSubfieldStructure( '', { unsafe => 1 } ); Some tests are failing is run twice Use of uninitialized value $code_wanted in string eq at /usr/share/perl5/MARC/Field.pm line 314. [x~10] Use of uninitialized value $code_wanted in string eq at /usr/share/perl5/MARC/Field.pm line 314. # Failed test 'Value is mapped correctly for column biblionumber' # at t/db_dependent/Koha/Item.t line 115. # got: undef # expected: '483' [etc.] Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23807 [Bug 23807] Add Koha::Item->as_marc_field -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 26984] New: Tests are failing if AnonymousPatron is configured
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26984 Bug ID: 26984 Summary: Tests are failing if AnonymousPatron is configured Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org After bug 14708 we are blocking the removal of the anonymous patron. In some tests we are deleting data, like patrons, and the tests fail with "Deleting patron failed, AnonymousPatron is not deleteable" One example is t/db_dependent/Koha/Item.t # Failed test 'No tests run for subtest "pickup_locations"' # at t/db_dependent/Koha/Item.t line 340. [Deleting patron failed, AnonymousPatron is not deleteable]# Looks like your test exited with 255 just after 4. We must not remove data before the tests are run. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 14708] The patron set as the anonymous patron should not be deletable
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14708 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Pushed to oldstable |RESOLVED -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14708] The patron set as the anonymous patron should not be deletable
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14708 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor(a)tuxayo.net --- Comment #51 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26854] New: stage-marc-import.pl does not properly fork
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26854 Bug ID: 26854 Summary: stage-marc-import.pl does not properly fork Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org When stage-marc-import.pl forks, the child process closes STDOUT, but it does not close STDERR, which is also connected to the Apache httpd parent process. This means that the parent stage-marc-import.pl process becomes a zombie process, as Apache httpd (apache2 2.4.25 Debian 9 && apache2 2.4.29 Ubuntu 18.04 && apache2 2.4.33 openSUSE Leap 15.1) does not reap it, as you can see below: kohadev+ 32716 32712 74 02:17 ? 00:00:26 [stage-marc-impo] <defunct> kohadev+ 32725 1 28 02:18 ? 00:00:02 /usr/bin/perl /kohadevbox/koha/tools/stage-marc-import.pl The above happens when running CGI-only Koha or Plack-enabled Koha which does not proxy stage-marc-import.pl. Across 3 different Koha instances, I am experiencing different outcomes in the web browser, although ultimately the forked child process does stage the records (unless bug 26853 occurs). -- That said, I have noticed something interesting. On openSUSE with CGI, I'm seeing a 200 in the browser, although the AJAX request does not complete, so the polling of background-job-progress.pl does not happen. On Ubuntu 18.04 with Plack, Apache returns a 502 to the browser. On Debian 9 with Plack (koha-testing-docker), no status is returned but it doesn't timeout. Possibly differences include different Apache httpd behaviour and different Apache configuration. If we fix this issue, I think that we'll find that behaviour across the different instances becomes more consistent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 25504] New: Wrong API spec breaks plack without meaningul error
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25504 Bug ID: 25504 Summary: Wrong API spec breaks plack without meaningul error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Without the patches from 25482, if you start plack under D10, you get the output from bug 25482 comment 11. We should have something more meaningful to help the debug. -- You are receiving this mail because: You are watching all bug changes.

1 47

[Bug 25726] New: Holds to Pull made empty by pathological holds
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25726 Bug ID: 25726 Summary: Holds to Pull made empty by pathological holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com After upgrading to 19.11, we're seeing libraries where pendingreserves.pl comes up empty when it shouldn't be. After some digging, we found it was because the library had some bad holds in their reserves table -- lines where reserves.itemnumber is null but reserves.found is not null. That runs into an issue on this line of the Holds to Pull query: AND items.itemnumber NOT IN (select itemnumber FROM reserves where found IS NOT NULL) I don't know exactly what changed between 19.05 and 19.11 to change how Koha thinks about this. I also don't know how libraries have ended up with these pathological holds. But that's a separate bug. To recreate: 1- place 2 bib-level holds on available items 2- confirm they both show on Holds to Pull 3- edit one hold from the database to set found='T' 4- reload Holds to Pull, confirm it is now empty -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25313] New: Add optional skip_merge parameter to ModAuthority
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25313 Bug ID: 25313 Summary: Add optional skip_merge parameter to ModAuthority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Just like in DelAuthority. Allows you to skip merge in batch transactions where you know that the merge is useless because the reporting tag did not change. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 26337] New: Remove unused authorities script should skip merge
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26337 Bug ID: 26337 Summary: Remove unused authorities script should skip merge Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Remove unused authorities checks if an authority is used If not it calls DelAuthority DelAuthority checks if the authority is used and removes it from records if it is. We should pass 'skip_merge' when calling form this script as we have already checked the usage here -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 26944] New: Help link from automatic item modification by age should go to the relevant part of the manual
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '20

10 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26944 Bug ID: 26944 Summary: Help link from automatic item modification by age should go to the relevant part of the manual Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Help link from automatic_item_modification_by_age.pl just goes to the manual home page. It should go to https://koha-community.org/manual//latest/en/html/tools.html#automatic-item… (or the proper version). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12