What is kohadevbox?

As the README.md at https://gitlab.com/koha-community/kohadevbox says – “Create a development environment for the Koha ILS project. It uses Vagrant and Ansible to set up a VirtualBox.” Basically it automates the long and somewhat complex process of manually setting up a development system for #kohails.

Why PuTTY?

From the website – PuTTY is an SSH and telnet client, developed originally by Simon Tatham for the Windows platform. PuTTY is open source software that is available with source code and is developed and supported by a group of volunteers. It is our go-to tool on Windows for accessing physical Koha boxes or VMs via SSH.

Vagrant sets up SSH service on the VM to use public-key authentication. Therefore our PuTTY instance needs to know the private key that Vagrant had setup inside the VM, in order to login into it. As many posts in Stackoverflow indicates, this is a point where many people get stuck. Usually they try with %USERPROFILE%\.vagrant.d\insecure_private_key and that typically fails.

Steps for kohadevbox

Using git-bash go to the directory where you had cloned kohadevbox. Be default it will be %USERPROFILE%/git/kohadevbox if you have simply followed the instructions from kohadevbox README.md file. In our case, it was %USERPROFILE%/gitdev/kohadevbox as we had changed it.

Run the command

vagrant ssh-config

You should see something like this:

The line to note in the output is IdentityFile. That’s the private key you need to grab and feed to PuTTYGen for it to convert it into a PuTTY compatible .ppk format private key.

NOTE: This path to the key is going to be different for different users, so do not attempt to copy-paste what you see here, instead use your own IdentityFile value.

Now we convert the vagrant_private_key from IdentityFile and save it as a .ppk file.

And lastly we import it into PuTTY like this and we are good to go!

Finally we are logged in into the VM

NOTES: The versions of software used – (a) PuTTY.exe – 0.71 (b) Vagrant – 2.2.7 (c) Git Bash – 2.25.0 (d) VirtualBox – 6.1.2

The Problem

Earlier this morning, Pranab Roy who manages the Library at the Karnavati University‘s UnitedWorld School of Business‘s Kolkata campus popped up on WhatsApp with a question – “Sir, why is Koha not showing the barcode / accession number of a borrowed document when an user logs in into their own account via the OPAC?”

This is what he meant. And this is actually the expected behaviour, with Koha doing exactly what it was asked to do. I could understand his confusion since the OPAC search’s details view showed the barcode quite nicely, then why not for the users themselves?

A bit of backstory

Karnavati University Libraries had shifted to L2C2 Technologies‘ cloud platform from a pre-existing Koha instance maintained by a 3rd party. As such the system had quite a few issues. While we had fixed a larger number of these during the initial on-boarding stage, some of these are getting ironed out only now as the librarians hit these “bumps on the road”. Pranab’s problem was one such.

The Solution

The option to display the barcodes for a logged-in OPAC user’s checkouts (issues) is driven by the SHOW_BARCODE patron attribute. In Koha, patron attributes or more correctly ExtendedPatronAttributes are library-defined custom fields that can be applied to patron records e.g. voter / aadhaar card number, registration number etc.

SHOW_BARCODE is a boolean variable that is defined as either Yes or No. and it is loaded into Koha usually during the web-installer phase of Koha’s installation from the optional SQL dump file: /usr/share/koha/intranet/cgi-bin/installer/data/mysql/en/optional/patron_atributes.sql in Debian package based installations. The tiny file contains a single SQL INSERT statement:

INSERT INTO `borrower_attribute_types` (`code`, `description`, `repeatable`, `unique_id`, `opac_display`, `staff_searchable`, `authorised_value_category`) VALUES (‘SHOW_BCODE’, ‘Show barcode on the summary screen items listings’, 0, 0, 1, 0, ‘YES_NO’);

In the case of Karnavati University this optional patron attribute was not imported during the *original* installation done by the 3rd party support provider at the time. And without “SHOW_BARCODE” being set, Koha had no way of displaying the barcodes of checked out books to patrons logged in via the OPAC.

In the end, the following two lines followed by enabling the ExtendedPatronAttributes system preference cleared off the issue for Karnavati:
$ cd /usr/share/koha/intranet/cgi-bin/installer/data/mysql/en/optional
$ mysql -uroot -p koha_karnavati .

A memcached restart later (to be safe rather than sorry) the OPAC started showing the barcodes to logged-in patrons.