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

[Bug 30572] New: Field search_marc_to_field.sort needs syncing too
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30572 Bug ID: 30572 Summary: Field search_marc_to_field.sort needs syncing too Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org $DBversion = '20.11.03.003'; if( CheckVersion( $DBversion ) ) { $dbh->do( "UPDATE search_marc_to_field SET sort = 1 WHERE sort IS NULL" ); $dbh->do( "ALTER TABLE search_marc_to_field MODIFY COLUMN sort tinyint(1) DEFAULT 1 NOT NULL COMMENT 'Sort defaults to 1 (Yes) and creates sort fields in the index, 0 (no) will prevent this'" ); kohastructure: CREATE TABLE `search_marc_to_field` ( `sort` tinyint(1) DEFAULT NULL COMMENT 'true/false creates special sort handling, null doesn''t', -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 29844] New: Remove uses of wantarray in Koha::Objects
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29844 Bug ID: 29844 Summary: Remove uses of wantarray in Koha::Objects Change sponsored?: --- Product: Koha Version: unspecified 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 They proved problematic, specially for template usage. Devs requiring list assignment should rely on ->as_list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 91

[Bug 18559] New: Koha:: Clubs - methods should not get the return type in parameter
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18559 Bug ID: 18559 Summary: Koha::Clubs - methods should not get the return type in parameter Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: kyle(a)bywatersolutions.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 12461, 18553 Koha::Clubs->get_club_enrollments and Koha::Clubs->get_enrollable_clubs take a $return_scalar parameter. The return value type should not be a parameter. We should return _new_from_dbic or Koha::Objects->search in any cases. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 [Bug 12461] Add patron clubs feature https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18553 [Bug 18553] Incorrect "Loading..." tag on moremember.tt when no clubs defined -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 26045] New: Search/History.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26045 Bug ID: 26045 Summary: Search/History.t is failing randomly 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 Blocks: 25551 Master_D10 #302 16:14:22 koha_1 | # Failed test 'There are 9 searches in all' 16:14:22 koha_1 | # at t/db_dependent/Search/History.t line 48. 16:14:22 koha_1 | # got: '10' 16:14:22 koha_1 | # expected: '9' 16:14:22 koha_1 | 16:14:22 koha_1 | # Failed test 'There are 4 searches for previous sessions' 16:14:22 koha_1 | # at t/db_dependent/Search/History.t line 61. 16:14:22 koha_1 | # got: '5' 16:14:22 koha_1 | # expected: '4' 16:14:22 koha_1 | 16:14:22 koha_1 | # Failed test 'There are 5 searches for the current session' 16:14:22 koha_1 | # at t/db_dependent/Search/History.t line 82. 16:14:22 koha_1 | # got: '5' 16:14:22 koha_1 | # expected: '4' 16:14:22 koha_1 | # Looks like you failed 3 tests of 27. 16:14:22 koha_1 | [14:14:22] t/db_dependent/Search/History.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25551 [Bug 25551] [OMNIBUS] Some tests are failing randomly -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 26056] New: `dbic` generates changes to EDI related schema files with latest MariaDB
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26056 Bug ID: 26056 Summary: `dbic` generates changes to EDI related schema files with latest MariaDB Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor 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 Maybe a bug in latest MariaDB (10.5.4) modified: Koha/Schema/Result/Aqbasket.pm modified: Koha/Schema/Result/Aqbookseller.pm modified: Koha/Schema/Result/Aqbudget.pm modified: Koha/Schema/Result/Branch.pm modified: Koha/Schema/Result/EdifactEan.pm modified: Koha/Schema/Result/EdifactMessage.pm modified: Koha/Schema/Result/VendorEdiAccount.pm Stuffs like: +__PACKAGE__->has_many( + "edifact_messages_2s", + "Koha::Schema::Result::EdifactMessage", + { "foreign.basketno" => "self.basketno" }, + { cascade_copy => 0, cascade_delete => 0 }, +); +__PACKAGE__->has_many( + "edifact_messages_2s", + "Koha::Schema::Result::EdifactMessage", + { "foreign.vendor_id" => "self.id" }, + { cascade_copy => 0, cascade_delete => 0 }, +); +__PACKAGE__->has_many( + "vendor_edi_accounts_2s", + "Koha::Schema::Result::VendorEdiAccount", + { "foreign.vendor_id" => "self.id" }, + { cascade_copy => 0, cascade_delete => 0 }, +); and more... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20502] New: Record URL broken, when there is more than one 856 on the record
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20502 Bug ID: 20502 Summary: Record URL broken, when there is more than one 856 on the record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com When there is more than one 856 in the record, the Record URL in the course reserves table creates a broken link. Example form the sample data: http://www.loc.gov/catdir/enhancements/fy1010/2009039494-b.html%20|%20http:… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 18768] New: Add the ability to authenticate patrons against other ILSs via SIP2
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18768 Bug ID: 18768 Summary: Add the ability to authenticate patrons against other ILSs via SIP2 Change sponsored?: Sponsored Product: Koha Version: master Hardware: All URL: https://github.com/kylemhall/Koha/commits/sip2_client 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 This feature allows Koha use to use other ILSs as an authenticate target in a manner someone similar to how we authenticate LDAP. It allows Koha to be configured with a list of external SIP2 servers to authenticate against. Koha will find the correct server to use based on the order and cardnumber prefix chosen, send a patron information request and handle the patron login based on the response. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 26641] New: link_bibs_to_authorities.pl: Add the ability to specify the MARC field to operate on
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26641 Bug ID: 26641 Summary: link_bibs_to_authorities.pl: Add the ability to specify the MARC field to operate on 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: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When running link_bibs_to_authorities.pl, it could be useful to have the ability to specify which MARC field the script should operate on. For example, when you have a catalog where most links are in place, and you don't want the script to process every MARC field but rather limit it to a specific MARC field (e.g. 700) because you've observed that there are many missing links for that particular MARC field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 26117] New: itemlost_on value should be updated when item changes from one lost value to another
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26117 Bug ID: 26117 Summary: itemlost_on value should be updated when item changes from one lost value to another Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: - set an item to lost=1 - get the itemlost_on value for your item from the database - change the item to lost=2 - get the itemlost_on value again, confirm that the time hasn't changed I'm sort of torn on this. Just now, we ran into an issue where it we needed to know when a lost value was changed. But I can also imagine a situation where one would want to know when an item became lost originally. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 26112] New: Errors in marc21_authorities files for uk-UA
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26112 Bug ID: 26112 Summary: Errors in marc21_authorities files for uk-UA Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: b.pastern4k(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 107630 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=107630&action=e… uk-UA fixed queries for default authority Upon fresh install when I choose to add authorities, the following error shows near every authorities file install.pl: DBD::mysql::st execute failed: Incorrect integer value: '' for column `koha_sql`.`auth_tag_structure`.`repeatable` at row 1 After completing install, I tried executing those SQL commands in phpmyadmin and it seems that in mandatory and repeatable columns have values '' or 1. I tried replacing those empty strings with zero and it worked. Seems like each SQL query in those files should be checked and columns mandatory, repeatable should only have values 0 or 1 as it is type tinyint(4). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22