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

[Bug 25139] New: POS explodes in error when trying to display older transactions
by bugzilla-daemon＠bugs.koha-community.org 06 May '20

06 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25139 Bug ID: 25139 Summary: POS explodes in error when trying to display older transactions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Fines and fees Assignee: martin.renvoize(a)ptfs-europe.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When trying to display older transactions in the POS module, there is an error: Template process failed: undef error - The given date (12.04.2020) does not match the date format (iso) at /home/vagrant/kohaclone/Koha/DateUtils.pm line 168. at /home/vagrant/kohaclone/C4/Templates.pm line 122 URL: http://localhost:8081/cgi-bin/koha/pos/register.pl?trange_f=07.04.2020&tran… It looks like the dateformat is not handled correctly here. Dateformat is set to DD.MM.YYYY -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 9290] Restricting patron category for online purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 06 May '20

06 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9290 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org --- Comment #15 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Maybe we could reuse the existing suggestion system preference: Suggestion = if suggestions are available in staff OpacSuggestion = if suggestions are available in OPAC Or make it a pref with 3 entries: Allow suggestions in (OPAC and staff interface|in staff interface|not at all) Native speakers might do better at phrasing these. And maybe: OpacSuggestionValidCategories ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20728] New: Remove subroutines GetLastOrder*
by bugzilla-daemon＠bugs.koha-community.org 06 May '20

06 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20728 Bug ID: 20728 Summary: Remove subroutines GetLastOrder* Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement 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 Depends on: 20276 There are 2 subroutines from C4::Acquisition that could be removed: - GetLastOrderReceivedFromSubscriptionid - GetLastOrderNotReceivedFromSubscriptionid After bug 20726 only GetLastOrderReceivedFromSubscriptionid will be used (from acqui/neworderempty.pl) and this call could be replaced easily with Koha::Acquisition::Orders The code (+ tests) related to these 2 subroutines could then be removed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20276 [Bug 20276] GetCourseItem is using the wrong call to get itemnumber -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 23914] New: SQL Server Version
by bugzilla-daemon＠bugs.koha-community.org 06 May '20

06 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23914 Bug ID: 23914 Summary: SQL Server Version Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hea Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: jonathan.druart(a)bugs.koha-community.org It would be really interesting to collect the sql server versions people are using in HEA. I'm interested to see what the adoption of MariaDB is and whether we can start adopting more recently introduced features from either MySQL or MariaDB (like CHECK constraints). -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 20370] Misleading comment for bcrypt - #encrypt it; Instead it should be #hash it
by bugzilla-daemon＠bugs.koha-community.org 06 May '20

06 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20370 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable Version(s)|20.05.00 |20.05.00, 19.11.06 released in| | CC| |joy(a)bywatersolutions.com --- Comment #5 from Joy Nelson <joy(a)bywatersolutions.com> --- backported to 19.11.x for 19.11.06 -- You are receiving this mail because: You are watching all bug changes.

1 0

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

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #19 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- (In reply to Martin Renvoize from comment #16) > I'm afraid we cannot yet use the 'IF EXISTS' syntax here as we are > maintaining support for Jessie up to the end of it's LTS date (2020-06-30). > I intend to drop support for that Debian version at the release of 20.05 (at > which time I believe we should also drop support for it from 19.11 at > 19.11.06 and 19.05 at 19.05.12). > > However, even once we have dropped such support, unless I am mistaken, > stretch is still stuck at MySQL 5.5 (though it recommends MariaDB instead. > As such, we'll need a clear deprecation of mysql 5.5 support outlined and > publicised before we can make this change. > > I am, however, pretty keen to take such an approach and drop 5.5 support > with this release and so this patch is 'on hold' for now. Is there an existing place like in the wiki that contains these info? Nothing more than you said, the current situation and future plans. -- You are receiving this mail because: You are watching all bug changes.

1 0

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

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #18 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- > 2) Remove the instance completely using `koha-remove`. I'm having an issue here. Maybe it's my dev environment. root@4dfd0fcc251b:kohadevbox$ koha-remove kohadev Removing Koha instance kohadev [ ok ] Stopping Plack daemon for kohadev:. userdel: user kohadev-koha is currently used by process 1005 /usr/sbin/deluser: `/usr/sbin/userdel kohadev-koha' returned error code 8. Exiting. Using koha-disable doesn't help. There are still starman and apache processes running that are from the unix user of the instance. Could there be anything more to do before removing the instance? -- You are receiving this mail because: You are watching all bug changes.

1 0

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

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor(a)tuxayo.net --- Comment #17 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- For some reason comment 15 doesn't have the test plan. But it turns out the patch has a test plan. Here it is, to remove confusion and help discussing it: Subject: [PATCH] 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. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25264] New: Add ability to process phone notifications without Talking Tech
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25264 Bug ID: 25264 Summary: Add ability to process phone notifications without Talking Tech 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 We have a partner that would like to use Twilio for phone notifications. The problem is that our phone notifications are Talking Tech-centric, and the way our TT is engineered is odd to say the least. We specifically don't create the notices in Koha, but have TT create them instead. I think it would be good to have a system preference that allows phone notices to act in a 'normal' manner so to speak much like email and sms notices. Future outbound calling systems could then just be plugins that handle phone notices while Koha handles email and sms. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23986] New: Batch Record Deletion does not remove records from search index
by bugzilla-daemon＠bugs.koha-community.org 05 May '20

05 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23986 Bug ID: 23986 Summary: Batch Record Deletion does not remove records from search index Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com To test: - create a bib record - perform a search that returns a list of results including your record - delete record via batch record delete tool - repeat your search, observe that record still appears in results - click deleted title in search results, get "The record you requested does not exist" error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21