- Koha-devel - lists.koha-community.org

Build slection of Jquery-UI
by Zeno Tajoli 17 Feb '21

17 Feb '21

Hi to all, last days I'm starting to use JQuery-UI much more. I find that in Koha there aren't all sections of JQuery-UI but only a selection. In opac: widget.js, position.js, data.js, keycode.js, scroll-parent.js, unique-id.js, widgets/sortable.js, widgets/autocomplete.js, widgets/datepicker.js, widgets/menu.js, widgets/mouse.js, widgets/slider.js, widgets/tabs.js, widgets/tooltip.js with version 1.12.1 In staff the list is: core.js, widget.js, mouse.js, position.js, draggable.js, droppable.js, sortable.js, accordion.js, autocomplete.js, button.js, datepicker.js, menu.js, progressbar.js, slider.js, tabs.js, effect.js, effect-highlight.js with version 1.11.4 There are specific motivation behind those different lists ? What do you think if I propose to add the dialog widget ( https://api.jqueryui.com/dialog/) to opac and staff ? Cheers Zeno Tajoli

5 4

Testing Docker Issue
by Andrew Fuerste-Henry 17 Feb '21

17 Feb '21

Hi folks! A couple of us within ByWater have run into testing docker issues recently. When trying to start up testing docker on master, one gets a bunch of SQL errors before the koha process just dies. It seems to be ok with starting up on a different branch and then switching to master after the fact. Has anyone else seen this? -- Andrew Fuerste-Henry Educator (he/him/his) ByWater Solutions bywatersolutions.com Phone:(888)900-8944 <(888)%20900-8944> What is Koha? <http://bywatersolutions.com/what-is-koha/>

5 7

Announcing an alternate indexing daemon for Zebra which is more memory efficient
by dcook＠prosentient.com.au 17 Feb '21

17 Feb '21

Hi all, I've written a new indexing daemon for Zebra which you can find at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27267. It's dead easy to use. Once the daemon is installed, you just need to update /etc/default/koha-common and you'll be using it. It only uses 6MB of RAM (instead of the 170-180MB I've seen rebuild_zebra.pl use in daemon mode), so it scales well on servers that host many instances of Koha. (For example, if you have 50 Koha instances on a server, you'll use 300MB instead of 9GB for idle Zebra indexing daemons.) That said, this indexing daemon does launch rebuild_zebra.pl in non-daemon mode when necessary, so you still need to have memory available to do actual work. Making rebuild_zebra.pl more memory efficient is another task in itself and not a pressing issue atm. I'm planning to use it shortly myself, but I figured that I would share it with everyone else, so that everyone else could benefit from it too. Hope others enjoy it as much as I do. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 6

Occasional problems with koha-dump (LOCK TABLES)
by dcook＠prosentient.com.au 17 Feb '21

17 Feb '21

Hi all, I was testing koha-dump on a new Ubuntu 18.04 server I put together, and I noticed that 2 out of 3 instances were failing to dump. Here are the errors: mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces mysqldump: Got error: 1045: Access denied for user 'koha_<instance>'@'localhost' (using password: YES) when using LOCK TABLES The first isn't really relevant. The key one is the second one. You can workaround it by adding "--single-transaction" to mysqldump in koha-dump, but I'm still intrigued why it only happened to 2 out of 3 instances on that server. I haven't seen this issue on other 18.04 servers either. All the permissions and what not were the same across the instances, the database connections were sleeping, etc. Nothing made sense. mysql> show grants for 'koha_<instance>'@'localhost'; +--------------------------------------------------------------------------+ | Grants for koha_<instance>@localhost | +--------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'koha_<instance>'@'localhost' | | GRANT ALL PRIVILEGES ON `koha_<instance>`.* TO 'koha_<instance>'@'localhost' | +--------------------------------------------------------------------------+ Has anyone else had this problem? David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Time to translate: string freeze to prepare Koha 19.11.15 has begun
by Victor Grousset/tuxayo 16 Feb '21

16 Feb '21

Hi, saluton, hola, bonjour, String freeze is into effect as of now for the 19.11.x maintenance branch. The release is scheduled for the 22th. This means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Reminder: if you add or change a translation in version 19.11, then you must also copy it to 20.05 and 20.11. Otherwise your work will be lost for future versions. Happy translating, -- Victor Grousset/tuxayo

1 0

Call for news - Newsletter February 2021
by Koha Newsletter 13 Feb '21

13 Feb '21

I'm collecting news for this month's newsletter. Send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: -------------- * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. For events: * Please include dates for past events. If I can't find dates I may not add it. * Announcements for future events with dates to be announced are fine, e. g. Kohacon. * For past events, one month back is the cut-off. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! Michael Kuhn Editor, Koha Community Newsletter

1 0

Display Koha version in staff interface
by Fridolin SOMERS 11 Feb '21

11 Feb '21

Hi, There is a discussion in : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27497 I propose that the community makes a vote : Would you like to see more prominently Koha version in staff interface ? Where ? - In lower right corner - In Header - Bellow "About Koha" big link - Other ... I'm OK if we change nothing in the end. I made a plugin that can be adapted : https://github.com/biblibre/koha-plugin-intranet-version-in-header Best regards -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

1 1

TestBuilder float and decimal format differs from the values returned by database
by Lari Taskula 08 Feb '21

08 Feb '21

Hi devs, While working on patron data export ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028 ), I was trying to generate a bunch of test data with TestBuilder, and then compare them to what was returned by DBIx's search(). Unfortunately I couldn't do this, because most decimals from DBI/DBIx are returned in a different formatting to what TestBuilder has. Running an is_deeply() to compare the objects fails with: # Structures begin differing at: # $got->[0]{amount} = '90203.710000' (value returned by DBIx) # $expected->[0]{amount} = '90203.71' (value in HASHref generated by TestBuilder) This is because TestBuilder's _gen_real() forces the formatting to 2 decimal places. But there's more - My original idea to solve this issue was by using "column_info" provided by DBIx, and formatting the value to maximum decimal places allowed. But even if you follow the column's size definition, you will notice that there is a different behavior between data types "float"/"double" and "decimal". If it's a decimal, it stays in "stringified" format with all those trailing zeroes, but if it's a float, all the insignificant zeroes are dropped from the end. At some layer lower than DBIx (perhaps DBD::mysql?) there appears to be some formatting magic. A concrete example of this is when you have a FLOAT(10,4) and DECIMAL(10,4) columns and store "10.1000" in both columns, in the end the float becomes 10.1 and the decimal "10.1000". It's the same result with both DBI and DBIx. However, for example mariadb-client chooses to format both values as "10.1000". My other solution was to reload the row generated by DBIx in TestBuilder::_storeColumnValues() with discard_changes/get_from_storage method, but that 1. doesn't work for tables that do not have primary key (e.g. statistics), see DBIx::Class::ResultSource::_pri_cols_or_die(): Operation requires a primary key to be declared on 'Statistic' via set_primary_key at /home/koha/Koha/t/lib/TestBuilder.pm line 362 2. adds some overhead, although only into tests I would appreciate some ideas or improvements. I've created a Bug for this issue, see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27630 . There is a test to demonstrate the issue, and the previously mentioned attempts to solve this issue. P.S. Somewhat related bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20621 -- Lari Taskula CEO, Hypernova Oy PL 16 80101 Joensuu, Finland

2 2

Cross-browser automated testing in Javascript (Puppeteer/Playwright)
by dcook＠prosentient.com.au 04 Feb '21

04 Feb '21

Hi all, What do people think about doing our cross-browser automated testing in Javascript rather than Perl? We're already using Node.js for generating Koha's CSS: https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff _interface. I've been playing with Puppeteer and Playwright lately for non-test related browser automation, and they're pretty easy to work with. Playwright is based on Puppeteer, and their basic APIs are the same, so fairly interchangeable. (We'd need to use another library like Jest or Playwright-test to do the test evaluation.) It looks like we only have 6 files that use Selenium, so it wouldn't be a big drama to replace them. There is a Perl library https://metacpan.org/pod/Playwright but it's just a wrapper around Playwright anyway and it's so new that I'd be a bit wary of using it. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Zebra ICU / phrases-icu.xml / Bug 27299
by dcook＠prosentient.com.au 01 Feb '21

01 Feb '21

Hi all, Indexdata have confirmed that the default phrases-icu.xml shipped with Zebra (and Koha) is misconfigured. They're updating the default one in Zebra and I have a patch to update Koha at Bug 27299: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27299 It's an easy enough change to make, and I'll be updating it for all my ICU libraries. I encourage all you Zebra ICU users out there to update your phrases-icu.xml as I've suggested on Bugzilla. I think that you'll find it makes a world of difference. Cheers, David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2