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

Impossible to export config backups when using Debian packages
by dcook＠prosentient.com.au 16 Nov '20

16 Nov '20

Hi all, /cgi-bin/koha/tools/export.pl can be configured to allow you to "Export database" and "Export configuration". These files are typically generated by a cron running "koha-run-backups --days 2 --output /var/spool/koha". However, only the database can be exported. The configuration cannot due to permission issues. See the following terminal output: root@kohadevbox:koha(bug26791)$ ls -l /var/spool/koha/kohadev/ total 4856 -rw-r----- 1 root kohadev-koha 1001326 Nov 16 10:23 kohadev-2020-11-16.sql.gz -rw------- 1 root root 3968315 Nov 16 10:23 kohadev-2020-11-16.tar.gz I reckon that we either need to 1) fix the permissions to allow the web download, or 2) remove the web download option I thought there was a Bugzilla issue for this but I couldn't find it, so I thought that I'd email the listserv to see what people think (and if anyone knows the bug reference number). David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Should we back up /usr/share/koha on a daily basis as well?
by Andreas Roussos 15 Nov '20

15 Nov '20

Dear Developers, In a standard package installation, the backup tarballs taken by the `koha-common` daily cron job (which calls `koha-run-backups`, which in turn calls `koha-dump` for each Koha instance) do not include the default base directory (i.e. /usr/share/koha). Indeed, including the entire /usr/share/koha tree in every instance's backup tarball (for multi-tenant setups) would be superfluous (not to mention space-consuming). However, I think that some provision should be made so that a backup of the /usr/share/koha tree is taken on a daily basis. This could be kept at the top-level /var/spool/koha/ directory with a filename like common-YYYY-MM-DD.tar.gz or shared-YYYY-MM-DD.tar.gz. It should even be possible to pass the base directory path as an argument, in case it has been changed from the default. My reasoning behind this is that people often make local changes to the Koha codebase, or edit the Intranet/OPAC XSLTs, or adjust the Template Toolkit files to account for their needs. So it would be in the users' best interest to have Koha take regular backups of these files as well. Thoughts? Kind regards, Andreas

2 1

Call for News: November 2020 Newsletter
by Koha News 15 Nov '20

15 Nov '20

I'm collecting news for the November newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** 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 T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. 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. NOTE: This'll be my last call for the news as editor - Michael Kuhn has accepted the role of the Newsletter Editor. Thank you Michael! Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Release notes for 20.11 needed
by Jonathan Druart 12 Nov '20

12 Nov '20

Hi devs, I have added the "release-notes-needed" flags to the bug reports pushed for 20.11, where release notes are missing. I'd like you to make sure that, if you are the author of one of those, they will be filled in before the end of next week. The release notes of the to-be-released 20.11 are available at https://gitlab.com/koha-community/koha-release-notes/-/blob/master/release_… Also we need to prepare the "technical release notes" section. I have created a pad where we can work on it together - https://annuel.framapad.org/p/koha_20.11_tech_release_notes I have added the name of the relevant people next to each bullet. Feel free to add anything you think that might be worth highlighting! Cheers, Jonathan

4 4

Location of plugins in @INC
by dcook＠prosentient.com.au 12 Nov '20

12 Nov '20

Hi all, I was talking about how we could override default Koha modules with customized versions by just making sure those modules were located earlier in @INC. That got me thinking. at the moment we put Koha Plugins at the bottom of @INC, but we could actually put them at the start of @INC. They would be more dangerous as they'd be able to override any Perl module. but they would also be more powerful. In the context of a Koha where controllers are Perl modules (e.g. Mojolicious controllers) rather than Perl scripts, a plugin could override any controller in Koha. That could make for very powerful and seamless customizations. Anyway, something to think about. Cheers, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 3

Ideas for Koha Plugins
by dcook＠prosentient.com.au 10 Nov '20

10 Nov '20

Hi all, I was looking at Mark's bug report at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890, and it got me thinking about how we use Koha Plugins (amongst other things). I think it would be interesting to let Koha plugins touch the $template object before $template->output is called. That would give Koha plugins a lot more power without having to hardcode in specific methods and such into Perl scripts. The Perl script could lookup Koha plugins using a hard-coded key (e.g. opac/opac-detail.pl or opac/opac-detail), and then it would be the job of the Koha plugin to take things from there. As a related aside, at some point, I'm planning to replace "output_html_with_http_headers" and "output_with_http_headers" (as part of Bug 26845 probably), but I'm not quite there yet. I'm slowly in the process of building Mojolicious controllers to replace our CGI scripts, and I'm hoping to refactor some vital components of Koha so that our CGI scripts keep working, but the new Mojolicious controllers are able to re-use the same code and stay consistent. Anyway, it's just an idea. We could implement it in "output_html_with_http_headers", or we could just implement it in some important scripts like opac-detail.pl. I don't have any particular use-cases in mind (besides Mark's). Another idea would be to put more of the UI logic into Javascript and hook plugins in more dynamically with the Javascript at a per-page level (rather than only via IntranetUserJS and OpacUserJS), but I haven't thought too much about that. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 3

SQL Query not equal and NULL
by Fridolin SOMERS 05 Nov '20

05 Nov '20

Hi, From : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24379#c1 > This query does not return rows where login_attempts IS NULL. It will return accounts where login_attempts = 0 I only recently understood the behavior or NULL values in SQL queries for NOT IN and !=. Should be advice this in coding guide lines ? Is there a syntax better than another : col!=value / not(col=value) ? Best regards 🎃 -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

2 1

DBIx query or
by Fridolin SOMERS 05 Nov '20

05 Nov '20

Hi, I recently changed a call on Koha::Biblios->search() to use an arrayref instead of hashref : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26407 But I see there are both arrayref of hashref existing in code for "-or" query. What is the difference ? Is there a way we should choose in guidelines ? Best regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

2 2

Fail to migrate issuingrules from 19.05 to 20.05
by Philippe Blouin 04 Nov '20

04 Nov '20

Hello all, Simple question: am I interpreting right that '*' itemtypes in issuingrules fail to migrate to circulation_rules because of the constraint? DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`koha_vingt`.`circulation_rules `, CONSTRAINT `circ_rules_ibfk_3` FOREIGN KEY (`itemtype`) REFERENCES `itemtypes` (`itemtype`) ON DELETE CASCADE ON UPDATE CASCADE) [for Statement " INSERT INTO circulation_rules ( categorycode, branchcode, itemtype, rule_name, rule_value ) SELECT IF(categorycode='*', NULL, categorycode), IF(branchcode='*', NULL, branchcode), IF(itemtype='*', NULL, itemtype) , 'finedays', COALESCE( finedays, '' ) FROM issuingrules "] at ./installer/data/mysql/updatedatabase.pl line 20712. Migrating that DB can be long, so rather than re-test extensively, I figured I'd raise my hand and ask the community what I'm getting wrong. Migration goes from 19.05.04 to 20.05.04. Thanks in advance, -- Philippe Blouin, Directeur de la technologie Tél. : (833) 465-4276, poste 230 philippe.blouin(a)inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

3 3

Roles for 21.05
by Renvoize, Martin 04 Nov '20

04 Nov '20

Hi All, Last call for submissions to take on a role for the 21.05 release cycle before the vote at this evenings general meeting. It came to our attention that the release maintainer roles were looking sparse in the community developers meeting this afternoon. Victor has graciously offered to take on the oldoldstable again, and Tomas will take on oldstable if we don't get any other candidates. It would be great to have some new members of the team, and the oldstable maintainer role would be a great role to take on (with the support of myself, Tomas and the rest of the development team). The role is well described here: https://wiki.koha-community.org/wiki/Project_roles#Release_maintainer and the processes are well documented on https://wiki.koha-community.org/wiki/Release_maintenance. Do please feel free to replace Tomas's name on the roles page or reply here if you're interested. https://wiki.koha-community.org/wiki/Roles_for_21.05 Hope you are all well, *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager Community Release Manager (19.11, 20.05) *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize(a)ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info(a)ptfs-europe.com

1 0