Koha Patron Image Packer helper script

One-click utility to help build bulk patron image loader zip archive for users accessing Koha ILS from their Windows PCs.

Academic libraries like the ones in colleges, typically have a need to bulk upload patron images (of students) at the start of every school year. The photos are usually made available from their admissions office, named and numbered as per either unique enrollment id or student id of each student. The college libraries typically also utilize these same numbers as their library card numbers.

Of course, when several hundred patron images have to be imported, Koha’s bulk patron image upload option comes in very handy. It is available at More > Tools > Patrons and Circulation > Upload Patron Images. We can create a ZIP archive with all these uniquely named and numbered photos along with a manifest file named either DATALINK.txt or IDLINK.txt. The structure of the manifest file is simple – <cardnumber><separator><filename>. The <separator> can be a comma or a tab character.

The only kink in this work flow is that quite often we would see people creating that manifest by hand. This, as expected, quite often led to errors, and as a result they often had to make multiple runs at uploading the photos along with wasting precious time identifying the errors in the manifest.

So when our client-partner Basanti Devi College Library wanted to upload several hundred patron images at one go, we decided to put together a small PowerShell script that could automate this function so that it could get done quickly, without any error and at the click of the mouse.

The Koha Patron Image Packer is the outcome. It is small PowerShell script that allows users working on Windows based system to build their bulk patron image batch loader zip file along with it’s IDLINK.txt manifest with just a single click. It’s minimum requirements are PowerShell v 3.0 script with .NET Framework 4.0.

Get the code

The code is available from https://gitlab.com/indradg/koha-patron-image-packer

Installation

Installation is nothing more than copying the datalinker.ps1 file over to folder which is holding your patron images named as per their cardnumbers in Koha.

However, before your Windows system may allow you to run an PowerShell script, it may be require you to set your ExecutionPolicy to RemoteSigned for your CurrentUser. To do that, go to Run and type in PowerShell and hit enter to open up the Windows PowerShell interactive console and type in the following command:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

To check if this has been set currently you can run the command and check the output by typing in

Get-ExecutionPolicy -List

Demostration

A screencast of this feature at work is available on Youtube. It is a short video under 2 minutes. Watch it at 720p at full-screen if supported on your bandwidth.

License

It is released under GNU GPL v3 or later, the same license as Koha.

Acknowledgment

A.J. Tomson, Librarian, Devagiri College, Kozhikode who wrote an early version of analogous script in Python in Koha 3.12 days.

Vimal Kumar V. whose blog post “A useful script to compress patron images to upload” had originally put the spotlight on Mr. Tomson’s work.

RTFM Series : Memcached and “DBI Connection failed: Access denied for user [..]”

Stumped by the Koha v 18.05’s refusal to access the database after a koha-remove followed by a koha-create using the same instance name? Then read on!

This post applies strictly to Koha 18.05 which was released on May 24, 2018. The new version with its new features has created a lot of excitement among the user. However the version has some major changes and unless you **CLOSELY** read and understand the release notes you will asking for trouble.

In this post we are going to talk about Memcached which is turned on by default from 18.05. If you overlook this fact, you may see yourself wasting hours trying to troubleshoot a problem, which may inexplicably (not quite even though it looks that way) go away after re-starting your system.

Last weekend my young friend Jayanta Nayek spent nearly a day trying to understand why he was getting the error – “DBI Connection failed: Access denied for user” whenever he tried to access the web-installer part of the staff client on his new 18.05 instance. Since he was on a test system, he had followed the old rinse-and-repeat routine. So when his installation did not work out for the first time, he ran sudo koha-remove library and then re-ran sudo koha-create --create-db library to start afresh.

When he re-created the instance i.e. “library”, he was stumped with the following error :

Software error:

DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access denied for user 'koha_library'@'localhost' (using password: YES) at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1490. at /usr/share/koha/lib/Koha/Database.pm line 103

Of course, when he tried to access the koha_library database from the mysql command-line client using the user and pass from his /etc/koha/sites/library/koha-conf.xml, it worked perfectly. But if he came back to the browser and tried to access the web-installer, the error would return.

So what was happening here? In one word – memcached! Memcached is an open source, distributed memory object caching system that alleviates database load to speed up dynamic Web applications. The system caches data and objects in memory to minimize the frequency with which an external database or API (application program interface) must be accessed. (Source: What is Memcached?).

In simple terms what this means for Koha is that memcached caches the frequent database queries fired off by Koha. And if an SQL result set has not changed since it was last queried *and* is already stored into memcached, it offers the data from in-memory hashes rather than using a more time-consuming database lookup process. Memcached (along with plack is intended to make Koha work faster under heavier loads).

When Jayanta would run sudo koha-remove library and followed it up with sudo koha-create --create-db library the Memcached server was not restarted, and kept holding on to the *original* database access hashes. Whereas following koha-create command to re-create the instance, the database authentication credentials (user & pass values from koha-conf.xml) were changed. That is why when he tried to directly access via the mysql command line client, it worked as the CLI client did not know about memcached. But when he tried to access the web-installer it failed as the connection query hash offered up from memcached had the old and not longer existing credentials.

So, if any reader of this blog should find themselves facing a problem like this, simple run the command sudo service memcached restart and once memcached has restarted, access the web-installer. It will work this time. Since memcached is an in-memory storage, the restart clears up the hashes and when the web-installer tries to access the database, it leads to what is called a “cache-miss” and thus the queries get run against the actual DB using the access credentials stored in koha-conf.xml.

And for goodness sake READ THE RELEASE NOTES 😉