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

[Bug 27276] New: borrowers-force-messaging-defaults throws Incorrect DATE value: '0000-00-00' even though sql strict mode is dissabled
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27276 Bug ID: 27276 Summary: borrowers-force-messaging-defaults throws Incorrect DATE value: '0000-00-00' even though sql strict mode is dissabled Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: somesecretemail(a)mailinator.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When running borrowers-force-messaging-defaults.pl the error message DBD::mysql::st execute failed: Incorrect DATE value: '0000-00-00' [for Statement "SELECT DISTINCT bo.borrowernumber, bo.categorycode FROM borrowers bo LEFT JOIN borrower_message_preferences mp USING (borrowernumber) is displayed. According to documentation this relates to MySql variable sql_mode and that the following behavior can occur if sql_mode contains NO_ZERO_IN_DATE and/or NO_ZERO_DATE. I can confirm this by executing set sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE'; SELECT * FROM borrowers WHERE borrowers.dateenrolled >= '0000-00-00' The select query will result in "Incorrect DATE value: '0000-00-00'" If I instead write set sql_mode='ALLOW_INVALID_DATES'; SELECT * FROM borrowers WHERE borrowers.dateenrolled >= '0000-00-00' the select query executes correctly and returns a collection of borrowers BUT borrowers-force-messaging-defaults.pl still produces the error. Things I've checked * restarting MySql service * restarting server * that <strict_sql_modes>0</strict_sql_modes> in koha-conf.xml is set to 0 * that /etc/mysql/mysql.conf.d/mysqld.cnf contains sql_mode = "ALLOW_INVALID_DATES" Is this a bug in Koha or is there some configuration that I'm missing? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 27004] New: Deleting a staff account who have created claims returned causes problem in the return_claims table because of a NULL value in return_claims.created_by.
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27004 Bug ID: 27004 Summary: Deleting a staff account who have created claims returned causes problem in the return_claims table because of a NULL value in return_claims.created_by. Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a staff deletes another staff member's staff account and that particular account happens to have created return_claims, it creates a NULL value in the return_claims.created_by, causing a problem when another staff tries to resolve the claims. On the patron's account Claim tab, when one tries to resolve the claim, it will perpetually load without doing anything. Only way to fix is update the NULL value on the created_by and add a borrowernumber. Is there a way to transfer the claim to a different staff account? Should Koha allow the deletion of an account when there are still return_claims unresolved? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 27292] New: TablesSettings.GetColumns() returning nothing creates unexpected Javascript on request.tt
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27292 Bug ID: 27292 Summary: TablesSettings.GetColumns() returning nothing creates unexpected Javascript on request.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I was rebasing Bug 15565 when I noticed strange Javascript errors. The following code in master was the actual problem: columns_settings_borrowers_table = [% TablesSettings.GetColumns( 'circ', 'circulation', 'table_borrowers', 'json' ) | $raw %] At the moment in koha-testing-docker, this creates the following Javascript: "columns_settings_borrowers_table = " For some reason, this doesn't currently cause a problem because the next line is blank and that line is followed by "$(document).ready(function() {". Anyway, there should be data coming back there, so that's something to investigate... -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 26367] New: Warn in HoldsQueue if request itemtype set but request is not item specific
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26367 Bug ID: 26367 Summary: Warn in HoldsQueue if request itemtype set but request is not item specific Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 0 - set AllowHoldItemTypeSelection to 'Allow' 1 - Place a title level hold for a record with an item from Library A for delivery at Library A for a patron from Library A with an itemtype specified 2 - perl misc/cronjobs/holds/build_holds_queue.pl 3 - There are warns: Use of uninitialized value in hash element at /kohadevbox/koha/C4/HoldsQueue.pm line 523. Use of uninitialized value in string eq at /kohadevbox/koha/C4/HoldsQueue.pm line 523. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 26701] New: Deal with scripts in C4/SIP directory
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26701 Bug ID: 26701 Summary: Deal with scripts in C4/SIP directory Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com There are a number of Perl (and Python) scripts in the C4/SIP directory. These look like test scripts which shouldn't be on a production system. Perhaps we could relocate them to misc/ if we don't want to delete them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 26950] New: Checkin failure messages are unclear or too specific
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26950 Bug ID: 26950 Summary: Checkin failure messages are unclear or too specific 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently checkins can fail for one of two known reasons: 1 - Duplicate issue ids 2 - Anonymous borrower configuration issues In the first case we refer to the 'data problems' or 'data corrupted' section of the about page. All errors are on the 'System information' tab and this is what we should mention In the second case we refer to the data problems section, but information is in another section on the tab. Additionally, during checkin we issue an 'Error' but on the about page we call it a 'Warning' we should upgrade to error and specify what is broken -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 27263] New: Link to preferences mentioned in system preference descriptions
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27263 Bug ID: 27263 Summary: Link to preferences mentioned in system preference descriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Wherever a system preference description mentions another system preference the name of that preference should be a link. This eliminates a process where the user has to search for that preference. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 26171] New: Show biblionumber in search_for_data_inconsistencies.pl invalid MARCXML
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26171 Bug ID: 26171 Summary: Show biblionumber in search_for_data_inconsistencies.pl invalid MARCXML Change sponsored?: --- Product: Koha Version: master 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 23846 added a check for invalid MARCXML in search_for_data_inconsistencies.pl. But the error message does not show the biblionumber of invalid biblio record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 26996] New: Elasticsearch: Multiprocess reindexing sometimes doesn't reindex all records
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26996 Bug ID: 26996 Summary: Elasticsearch: Multiprocess reindexing sometimes doesn't reindex all records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: bjorn.nylen(a)ub.lu.se We've discovered that rebuild_elasticsearch.pl will not index all records in some cases using multiple cpu's. Sometimes one (or more) child proc. will loop through their records without ever committing them to ES. Symptoms are that the process will work faster than others, not log "Committing xxx records" and consume ever growing amount of memory. The problem appears to be in the fudging of commmit sizes for the childs. It generates a float which will in some cases never be == 0 as the buffer counter is decreased. This set of param will fail for me everytime ./rebuild_elasticsearch -v -b -p 2 -c 400 Will uplaod a patch shortly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 27310] New: Wrong CSS float on 'Visibility' in framework edition
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27310 Bug ID: 27310 Summary: Wrong CSS float on 'Visibility' in framework edition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In administration > framework edition > subfield edition, 'Visibility' label as a CSS rule float none. This seems obsolete, removing it will align label like others. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19