February 2021 - Koha-bugs - lists.koha-community.org

[Bug 27099] New: Stage for import button not showing up
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27099 Bug ID: 27099 Summary: Stage for import button not showing up Change sponsored?: --- Product: Koha Version: 19.05 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: eric.begin(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org Some of our clients report that the 'Stage for import' button disappeared in the Stage MARC records page. This problem seams to be related to Chrome 87. The button is still there, but hidden by the language bar at the bottom of the page. A temporary workaround is to add a margin to the <main> element in IntranetUserCSS In our case, we added main { margin-bottom: 50px; } The problem is also present on 20.05 No tested yet on master. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 27135] New: Viewing local cover images at item level shows a link to upload image at record level
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27135 Bug ID: 27135 Summary: Viewing local cover images at item level shows a link to upload image at record level 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When viewing local cover images at item level : /cgi-bin/koha/catalogue/imageviewer.pl?itemnumber=X&imagenumber=Y Page shows a link to upload image at record level : /cgi-bin/koha/tools/upload-cover-image.pl?biblionumber=108&filetype=image This link should point to uploading at item level no ? PS : viewer should display some information about the item, like barcode. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 27031] New: Update header.inc to use Koha plugin for intranetbookbag
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27031 Bug ID: 27031 Summary: Update header.inc to use Koha plugin for intranetbookbag Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org header.inc is still using the [% intranetbookbag %] instead of using Koha.Preference('intranetbookbag'). -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 26953] New: Phone & SMS transports always displayed in overdue status triggers and notices editor
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26953 Bug ID: 26953 Summary: Phone & SMS transports always displayed in overdue status triggers and notices editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com While working on bug 25334, I noticed that even if a library is not using any phone transport, the phone column still shows on the overdue status triggers. A similar issue is prevalent in the notice editor. It would be nice if those things were hidden when no phone transport is set up. The same for SMS as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 27168] New: Most popular doesn't always sort correctly
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '21

11 Feb '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27168 Bug ID: 27168 Summary: Most popular doesn't always sort correctly Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexandra.speer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Most popular should always sort most popular items on top, but it doesn't. - Turn on: OpacTopissue Open the most popular page in the OPAC. -> The records should appear correctly. Now change - Show the top filter to 20 titles and - Acquired in the last to No limit and Submit -> The results are no longer sorted correctly by Checkouts. -- You are receiving this mail because: You are watching all bug changes.

1 22

[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