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

Centralize and move to gitlab
by Jonathan Druart 08 Aug '18

08 Aug '18

Hi devs, (Spoiler: I am not talking about a move from bugzilla to gitlab for the Koha git repo) Just a quick comment: gitlab has the ability to move projects with all the issues. >From the export page of a project, they say: """ The following items will be exported: Project and wiki repositories Project uploads Project configuration including web hooks and services Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities """ So that will be easy to move (already discussed with Chris, will do in May) * koha-community-devs-users/kohadocs to koha-community/kohadocs * https://gitlab.com/koha-dashboard/koha-dashboard to koha-community/koha-dashboard And the ones from github too: * joubu/koha-misc4dev to koha-community/koha-misc4dev * Koha-Community/qa-test-tools to koha-community/qa-test-tools Then, maybe: koha-testing-docker koha-release-notes kohadevbox koha-howto The idea is to centralize our things in one place, ease the PRs and the ability to clone/fork keeping the visibility on what is the reference (account 'koha-community'). I would also like to generate a CI configuration for some of them. CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146 (I am going to submit that on bugzilla soon) CI file for the manual: https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-c… Any pros/cons? Cheers, Jonathan (No troll please)

11 16

Koha Community Newsletter: July 2018
by Koha Newsletter 02 Aug '18

02 Aug '18

The Koha Community Newsletter for July 2018 is here: https://koha-community.org/koha-community-newsletter-july-2018/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. PS: please excuse the delay -- we had a baby the 20th of this month! Healthy baby girl. Thanks!

1 0

Batch cleanup to the catalog
by Cab Vinton 01 Aug '18

01 Aug '18

Hi, All -- Koha's Batch Record Modification (BRM) tool makes it very easy to make large-scale changes to the catalog. And we know that many catalogers like to have their records just so :-) Is there a cost in overhead, however, to making such changes? For example, if a catalog of 150,000 records contains 75,000 unwanted MARC fields, would you delete them, even if they're not displayed in the OPAC or otherwise interfering w/ functionality? In particular, I'm wondering whether using the BRM tool involves the creation of new data so that there's no real net gain w/ respect to the goal of having a "cleaner" database. (In our case, we've turned off the CataloguingLog system preference.) Along the same lines, are there any advantages to doing large-scale batch process via the backend instead, i.e., as opposed to w/ the built-in staff tools such as BRM? (I'm assuming there's no issue w/ using such tools to work w/ much smaller subsets of records.) Thanks in advance for any guidance. All best, Cab Vinton, Director Plaistow Public Library Plaistow, NH

2 2

ALTER IGNORE new policy?
by Philippe Blouin 31 Jul '18

31 Jul '18

Good day, everyone! Small inquiry here: Simply put, bz 17234 made an effort to remove the ALTER IGNORE from updatedatabase.pl so that it could work with Mysql 5.7. But playing with the master today, I got many errors related to it * 12395 - 18.06.00.005 * 19524 - 18.06.00.006 * 13560 - 18.06.00.008 Was there a change of policy regarding that, or is this something a bug should be opened or reopened about? Right now it kills our community development effort. Later on, it'll be our customers maintenance and I'll start to plan right now. Thanks! -- Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin(a)inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

3 4

Good commit messages
by David Cook 30 Jul '18

30 Jul '18

Hi all, So Jonathan linked me to this the other day: <https://wiki.koha-community.org/wiki/Commit_messages#Good_commit_messages_2 > https://wiki.koha-community.org/wiki/Commit_messages#Good_commit_messages_2 I don't understand one of the "Bad commit messages" though. I thought everyone always starts a good commit message with "Bug 12345 - ". Am I missing something there? Personally, I don't think you can always explain what the *bug* is in 50 characters, although I'm super on board for the commit message containing what the *fix* does. I'm writing a commit message for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21131 and struggling a bit as the bug is actually kind of convoluted. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 1

Formatting control number searches
by Barton Chittenden 27 Jul '18

27 Jul '18

I'm working on generating links for 7XX linking fields in XSLT, a-la Bug 15140 - Add MARC21 776 to OPAC and staff display ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15140) This Takes the 773$w, and uses the XSLT template 'extractControlNumber' which strips the leading MARCOrgCode, e.g. turning (OCoLC)2776588 into 2776588 ... and then the search URL is /cgi-bin/koha/opac-search.pl?q=Control-number:2776588 The problem is that 2776588 isn't the actual OCLC number -- The formatting rules are here: https://help.oclc.org/Metadata_Services/OCLC-MARC_records/Content_designato… In short: 0-8 digits: 0 pad to 8 digits, prepend 'ocm': 2776588 -> ocm02776588 9 digits, prepend 'ocn' > 9 digits, prepend 'on' I tried formatting the search with a leading '*': /cgi-bin/koha/opac-search.pl?q=Control-number:*2776588 as well as with leading and trailing '*' /cgi-bin/koha/opac-search.pl?q=Control-number:*2776588* Neither of these worked. Formatting the control number according to the OCLC rules above did work: /cgi-bin/koha/opac-search.pl?q=Control-number:ocm02776588 So I have three questions: 1) Is there a way to format a Control-number search that doesn't force me to generate the control number according to the OCLC rules above? 2) If not, does anyone have pointers about how to * Test for (OCoLC) -> * Test length of control number * < 9 -> 0 pad to 8 digits, prepend 'ocm' * 9 -> prepend 'ocn' * > 9 -> prepen 'on' 3) Are there other control number formatting rules for other MARCOrgCodes?

2 4

Koha Debian packages for 18.05.02 and 17.11.08 are up
by Mirko Tietgen 26 Jul '18

26 Jul '18

Hi, it's hot, no further text, ;) Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net

1 0

Koha 17.11.08 release
by Fridolin SOMERS 26 Jul '18

26 Jul '18

The Koha community is proud to announce the release of Koha 17.11.08. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-17-11-08-release/ Debian packages will be upgraded in a few days. Regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre, France - software and system maintainer

3 2

Koha reports wiki
by Cab Vinton 22 Jul '18

22 Jul '18

Hi, All -- Apologies for the cross-posting. The clean up of the Reports wiki page appears to have got stalled out: https://wiki.koha-community.org/wiki/SQL_Reports_Library (Large no. of duplicate listings of reports for holds, patrons, & circulation (HPC), which also appear on corresponding pages -- https://wiki.koha-community.org/wiki/SQL_Reports_Holds, etc.) I've identified the reports on the main page that aren't cross-listed (19 in total). I'd like to relocate these & then delete all the listings under the HPC categories on the main page. I suspect these pages see a lot of use, however, so I don't want to barge in and inadvertently make things worse. Anything I should be aware of before jumping in? All best, Cab Vinton, Director Plaistow Public Library Plaistow, NH

4 10

Client-side git hooks
by David Cook 21 Jul '18

21 Jul '18

Hi all, How many of you are using client-side git hooks? That is, git hooks that are in your working directory. A while ago, I added a "pre-commit" git hook in my Koha git working directory, which runs a little Python script every time I make a commit. It's nothing fancy. Basically it gets a list of all the files I'm changing in Git and for a ".pl" or a ".pm" file, it runs "perl -c", which compiles the Perl code without running it (with a caveat about BEGIN{} blocks which do get run at compile time so could be a problem if you're running untrusted code especially as a privileged user.). The Python script gets the exit code of that operation, and if there's an error, it uses an exit code of 1 itself and prevents the commit from happening. I've attached some sample code to the bottom of this email under "__PYTHON_SCRIPT__". I find that it's a nice way of catching errors. Maybe you write some code and you don't think you need to test it, or you tested it but you made a last minute change and that last minute change has a typo. this catches that kind of things - at least if it's an error which prevents successful compilation. Anyway, I was just porting a patch between different versions of Koha, and everything looked good at a glance and the code merge was successful, but the commit failed because one variable name in one line of the many lines changed was slightly different. The error messages told me exactly where to go and then it was obvious what the problem was and what to do. Anyway, I just thought I'd share that. Maybe everyone is already using client-side git hooks, but I thought I'd share just in case someone else finds it useful. Especially as it saved my bacon just now. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 __PYTHON_SCRIPT__ #!/usr/bin/env python import subprocess, os errors = 0 output = subprocess.check_output(["git","diff","--cached","--name-only","--diff-filte r=ACMR"]) lines = output.split('\n') for line in lines: if line: filename, file_extension = os.path.splitext(line) print(filename) print(file_extension) if file_extension == ".pl" or file_extension == ".pm": rv = subprocess.call(["perl","-c",line]) if rv: errors += 1 if errors > 0: exit(1)

5 4