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

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 Shi Yao Wang <shi-yao.wang(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 Shi Yao Wang <shi-yao.wang(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shi-yao.wang(a)inLibro.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20123] New: Allow multiple instances of Koha to have different timezones on the same server
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20123 Bug ID: 20123 Summary: Allow multiple instances of Koha to have different timezones on the same server 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Most of Koha depends on the local timezone of the server, except for Koha::Database which support an ENV override with the key TZ. We should take this a step further. We should not only accept the TZ environment variable for all of Koha, we should really be able to set the timezone in the koha conf file as well so we don't have to pass that environment variable to things like cronjobs and one-off scripts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 64

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #127865|0 |1 is obsolete| | --- Comment #43 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 133758 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=133758&action=e… Bug 10517: Use `DROP USER IF EXISTS` and remove ` || true`. When restoring a Koha instance, and the database user does not exist, an error is shown, although it is prevented from stopping the script by ` || true`. This patch removes the ` || true` guard, and rather uses `DROP USER IF EXISTS` which does exactly what one would expect, without confusing error messages, whether the user existed or not. To test: 1) Assume your Koha instance is called `asdf`. 1) Export the Koha instance using `koha-dump`. 2) Remove the instance completely using `koha-remove`. 3) Import it again using `koha-restore`. 4) No error should be shown, and the import should work. There was NO user to drop, therefore `DROP USER IF EXISTS` did nothing. 5) A database user called `koha_asdf` should exist, and have all privileges on the database of the same name. 6) Remove the instance again using `koha-remove`. 7) Now create a database user in MySQL called `koha_instance` where instance is the name of your dumped koha instance. 8) Import your koha instance again using `koha-restore`. 9) Again, no error should be shown, and the import should work. There WAS a user to drop, therefore `DROP USER IF EXISTS` dropped the user before creating a new one. 10) Again, a database user called `koha_asdf` should exist, and have all privileges on the database of the same name. Sponsored-by: Reformational Study Centre Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26839] New: Add a 'date published' feature to the facets
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26839 Bug ID: 26839 Summary: Add a 'date published' feature to the facets Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org Add a 'date published' facet to the OPAC so that patrons can limit their search results. For example: 2021 (2) 2020 (9) 2019 (14) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 10734] Add Publication Date Facet in Searching
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10734 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |barbara.johnson(a)bedfordtx.g | |ov --- Comment #10 from Owen Leonard <oleonard(a)myacpl.org> --- *** Bug 26839 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '22

25 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #27 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Hayley and all, trying to give this another push forward. 1) Unit tests (blocker) We are still missing the unit tests. Is there any update on that? 2) Database update The database update is still a bit too verbose, as noted earlier, using some uncommon output pattern (ALTERATION, NOTICE and INFO are not needed). We said RM could deal with it, so just explaining a bit more what people meant earlier on: +use Modern::Perl; + +return { + bug_number => "12029", + description => "Enable patrons to delete messages", + up => sub { + my ($args) = @_; + my ($dbh, $out) = @$args{qw(dbh out)}; + + # Do you stuffs here + my $alteration = q{ + ALTER TABLE messages + ADD COLUMN `patron_read_date` timestamp NULL DEFAULT NULL + COMMENT 'date and time patron dismissed message' + AFTER `manager_id` + }; + if( column_exists('messages', 'patron_read_date') ) { + say $out "NOTICE: Column 'messages.patron_read_date' already exists"; + } + else { + say $out "ALTERATION: $alteration"; + $dbh->do($alteration); + } + + # Print useful stuff here + say $out "INFO: Bug 12029 migration applied"; + }, +}; 3) Translatability There is some code in opac/dismiss_message.pl that I wondered about. It contains messages that are not translatable, but I am not sure yet if this would show to patrons, in my tests it didn't seem like it. comment => "Patron read date already set", comment => "Set patron_read_date to ($patron_read_date)", Hm, they might not be used after all? >11. What are you doing with $result? $inputs and comment are returned from the dismiss_patron_message sub but never >reused. This script could be 10 lines long IMO. Failing for 1). Testing in the GUI worked well! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14242] Use ISBN-field to fill out purchase suggestions (using an Ajax-request)
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '22

24 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 Amit Gupta <amitddng135(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amit.gupta@informaticsgloba | |l.com, | |amitddng135(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '22

24 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #58 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- 1) Capitalization It's all good, but in the database update statement: Canceled Hold Available for Different Patron', '0', 'Canceled Hold Available for Different Patron', 'The patron picking up <<biblio.title>> (<<items.barcode>>) has changed to <<borrowers.firstname>> <<borrowers.surname>> (<<borrowers.cardnumber 2) Spelling Should this be reply-to address? + - . If no address is defined here, the email will be sent to the library's reply to address. 2) Tests are failing :( prove t/db_dependent/Holds/ExpireReservesAutoFill.t t/db_dependent/Holds/ExpireReservesAutoFill.t .. 1/3 # No tests run! t/db_dependent/Holds/ExpireReservesAutoFill.t .. 2/3 # Failed test 'No tests run for subtest "Test automatically canceled expired waiting holds to fill the next hold, without a transfer"' # at t/db_dependent/Holds/ExpireReservesAutoFill.t line 131. Undefined subroutine &main::CancelExpiredReserves called at t/db_dependent/Holds/ExpireReservesAutoFill.t line 101. # Looks like your test exited with 11 just after 2. t/db_dependent/Holds/ExpireReservesAutoFill.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 2/3 subtests Test Summary Report ------------------- t/db_dependent/Holds/ExpireReservesAutoFill.t (Wstat: 2816 Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 11 Parse errors: Bad plan. You planned 3 tests but ran 2. Files=1, Tests=2, 3 wallclock secs ( 0.03 usr 0.00 sys + 2.66 cusr 0.30 csys = 2.99 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29135] New: OAI should not include biblionumbers from deleteditems when determining deletedbiblios
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '22

23 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29135 Bug ID: 29135 Summary: OAI should not include biblionumbers from deleteditems when determining deletedbiblios 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When including items in OAI we add the biblionumbers of deleted items into the deleted list This is from this line: 93 if ( $include_items ) { 94 $sql = "($sql) UNION (SELECT DISTINCT(biblionumber) FROM deleteditems $criteria)"; 95 push @bind_params, @part_bind_params; This is wrong because deletion of a single item does not indicate a record is deleted To recreate: 1 - Create /var/lib/koha/kohadev/OAI.yaml with: format: marcxml: metadataPrefix: marcxml metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim schema: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd include_items: 1 2 - Set OAI-PMH:ConfFile to '/var/lib/koha/kohadev/OAI.yaml' 3 - Delete an item from a record 4 - View the page: http://localhost:8080/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=m… 5 - Note the record is now listed as deleted -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36