Adding the item type filter to OPAC masthead search

Earlier today my good friend Vimal Kumar Vazaphally posted a question here about how to add the the item type (mc-itype in koha search speak) filter as a dropdown to the default main masthead search in the Koha OPAC.

Fig. 1: The default OPAC masthead search bar.
Fig. 1: The default OPAC masthead search bar.

RTFM and RTFM often!!! It may save your life!

<rant>The discussion that pursued on the FB group made something very clear. People forget to read the fine manual and when they do, they do not read “between the lines”. Trust me on this one, the Koha user manual is truly a ginormous treasure trove, if you take the pains to read it.</rant>

Ok! here is why I said that people really need to RTFM. The solution to the problem which Vimal shared can easily be extrapolated from this section in the manual – Appendix P: Extending KohaNewest title pulldown (#KohaTrivia it is based on a July 2012 blog post by Nicole C. Engard (Koha’s indefatigable Documentation manager).

“Reading between the lines” of a given solution

Here was the catch: Nicole’s solution pulled out only the newest arrivals of each itemtype, whereas we need it to pull out everything tagged to an itemtype, whether new or old. The second catch was that in Nicole’s example, she added plain HTML to the OpacNav system preference. However we are going to add it via the jquery / javascript route using the opacuserjs system preference.

We will follow Nicole’s example and pull out all item types that we need to populate the drop-down using SQL. However, we will need to escape the additional “backslash” (i.e. \ ) since we need MySQL to execute the query and actually generate the HTML markup that will be rendered on the browser via Javascript. Javascript does not care for arbitrary line breaks 😉 [1] and MySQL does not care about unescaped backslashes!

Now, if this sounded confusing, ponder for a moment on this Ajeet joke from yesteryears:

Raabert: Boss? Is kaa kyaa kare boss?
Ajeet: Rawbert! Is pille ko liquid oxygen me daal do. Liquid ise jeene nahi dega, aur oxygen ise marne nahi dega.

Nicole’s SQL based option list generator:
SELECT CONCAT('<option value=\"mc-itype:', itemtype, '\">',description,'</option>') FROM itemtypes

Our modification to the that make the output Javascript friendly:
SELECT CONCAT('<option value=\"mc-itype:', itemtype, '\">',description,'</option> \\') FROM itemtypes

In this case, turns out we have 5 itemtypes defined and we get this following output and we save it as CSV for introduction into our jquery.

<option value=”mc-itype:BBK”>Bengali Books</option>\
<option value=”mc-itype:BOOK”>Books</option>\
<option value=”mc-itype:BVOL”>Bound Volumes</option>\
<option value=”mc-itype:REF”>Reference Books</option>\
<option value=”mc-itype:SER”>Serials</option>\

(Hint: the exact item types is most likely to differ in your case; DO NOT copy-paste this output AS-IS.)

Let’s build the actual jQuery snippet

$( '<select name="limit" id="limitfiler" style="margin-left: 4px;"> \
<option value="">-- filter by item type --</option> \
<option value="mc-itype:BBK">Bengali Books</option> \
<option value="mc-itype:BOOK">Book</option> \
<option value="mc-itype:BVOL">Bound Volumes</option> \
<option value="mc-itype:REF">Reference Books</option> \
<option value="mc-itype:SER">Serials</option> \
</select>' ).insertAfter('#masthead_search');

And plug it into your opacuserjs system preference.

Let test our new drop-down!

add_itype_04
Fig 2: Searching for “Subject” as “English language” and no item-type based filtering
Fig 3: Additionally "BOOK" item type filter on.
Fig 3: Additionally “BOOK” item type filter on.
Fig 4: With REF itemtype filtering on.
Fig 4: With REF itemtype filtering on.

References:

[1] “Multi-Line JavaScript Strings” by David Walsh

Exporting your LibraryWorld bibliographic data to MARC21

Steps to export your LW data to MARC21 for import into Koha.

LibraryWorld (LW) is a hosted (SaaS) proprietary integrated Library system developed and promoted by San Jose, California based Libraryworld Inc. According to their website they charge USD 495 annually for a hosted instance of LW. So earlier in the day when Mr. Sonam Rinzee from Bhutan requested for some help in exporting his library’s catalog data, it presented the perfect opportunity for L2C2 Technologies to tinker with something new. These screenshots describe how it was done.

Step #1 : Access the LW website

lw_01

Step #2 : Login into the admin dashboard

lw_02

Step #3 : Go to Catalog module and click on “Advanced”

lw_03

Step #4 : Use the search filter like this

lw_04

Step #5 : Export the records

lw_05

Step #6 : Export as MARC using the export button

lw_06

Step #7 : Wait for your export to be ready. Click on “refresh” link to see if it is “done”

lw_07

Step #8 : Download the exported data by clicking on “FILE” link and change file extension to “.mrc”

lw_08

Step #9 : Open the file using MarcEdit and convert it to .mrk for edit work

lw_09

Step #10 : Now curate, remap and edit the data in a batch for making it import ready into Koha

lw_10

Published under CC 4.0 – BY – SA

Originally posted at https://www.facebook.com/pg/l2c2technologies/photos/?tab=album&album_id=993894330699800

Customizing Koha’s iconset to match page background

The world’s favorite open source ILS aka Koha ships with several iconsets included i.e. carredart, crystal-clear, seshat, bridge, npl, vokal etc. The primary use of these icon sets is to provide visual cues for different item types e.g. books, serials, DVDs, sound recordings, electronic materials etc. The icon set used by default is The Bridge Material Type Icon Set.
It is licensed under Creative Commons 2.5 Attribution, ShareAlike license.

This HOWTO will focus on how to customize the bridge iconset so that our icons match the OPAC page background. The iconset as shipped by Koha are in .gif format with a white background. This default works perfectly well when we stick with the default CSS of Koha, where the page background (the main div) is also white as seen below.

def_iconset

There are times when we may wish to customize the OPAC CSS using the opacusercss system preference, for instance in this case, we wanted to change the body.main div’s background-color to match our custom OPAC color theme:

/* change main div color */
div.main { background-color: #EAE9E7; }

But due to the white background of the Bridge iconset, the page now looked like this:

def_iconset_01

 

Obviously this needed to be fixed. We went to The Bridge Material Type Icon Set Project page and downloaded the zip file (downloaded from here) containing the original .psd files of the icons.

While you can use Photoshop to edit them, we used GIMP (GNU Image Manipulation Program) to edit the .psd files. We will use the book material type icon – book.psd for this example.

Instructions for editing the icons using GIMP

    1. Open book.psd in GIMP
    2. Check the layers – both visible and the ones turned off gimp_layers
    3. Set the foreground color to #EAE9E7 gimp_forecolor
    4. Add a new layer using using foreground color as set above gimp_newlayer
    5. Arrange the layers correctly with only the text layer, the graphic and the new layer using the color EAE9E7 being visible in proper order gimp_addedlayer
    6. Use GIMP’s Export As option in the File menu to create your new book.gif

Repeat the above steps until you have changed all the required icons. Save all the exported .gif files in a single directory / folder which we will call as “demolib” in this example.

Getting Koha to use the customized icons

N.B.: Koha stores the item type icons in two separate locations i.e. opac-tmpl/bootstrap/itemtypeimg/ (for the OPAC) and at intranet-tmpl/prog/img/itemtypeimg/ (for the staff client)

  1. Create an OPAC sub-folder for your customized icon set mkdir -p /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/itemtypeimg/demolib
  2. Create a staff client sub-folder for your customized icon set mkdir -p /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/img/itemtypeimg/demolib
  3. Copy all the .gif files in your local demolib folder into both the newly created sub-folders above. Note: You may need to use an FTP / SCP client to copy the files, if you Koha server is located on a remote machine.
  4. Navigate to Home -> Administration -> Item types administration on your Koha system.itemtypes
  5. Click on Edit option against the itemtype Book (BK). You should now be able to see a new icon set tab named “demolib” under the “Choose an icon” section def_iconset_03
  6. Select the new icon for the Book Item type from this demolib library and save the change.
  7. Repeat for each of the item types that you wish to update with your new customized iconset.

Now visit your OPAC page again and select the “Advanced search” option. This time Koha will be using your new icons and these will merge correctly with the page background.
def_iconset_02

PRO-TIP: Instead of editing the existing Bridge icon set, you can also create your own icon set. The usual icon sizes are 32×32 pixel or 40×40 pixel (Bridge uses this dimension). Design and save them to a specific folder and then follow the instructions in the section Getting Koha to use the customized icons. Demolib is just a name we are using here, you can change it to anything else as long as they are not the ones that are already used in Koha.

Setting up a MARC21 ETD Framework in Koha

Recently during a discussion on a Whatsapp group of professional colleagues from the North East, a topic that came up – what was better suited for setting up an ETD repository at their academic institutions? As expected, most sided with DSpace, while a few suggested Eprints. I decided to introduce Koha ILS into the picture. For most, this was a rather surprising suggestion.

The ground reality

95% of Indian ETD operators do very little than scanning up a batch of printed document (bound thesis volumes) or born-digital electronic copy of the theses, make it into a PDF file, throw in some metadata together about the item and plug that into (usually) DSpace. The benefits of DSpace being statistics, organisation into collections and community (user groups), embargo capability, faceted and full text searches across the metadata. There is of course the other point of persistent URLs to the hosted resources via HANDLE system. But given that very few Indian repos actually invest in a Handle.net account, it is quite a moot point.

The argument for Koha

Utilizing MARC21, Koha already offers a highly granular and extensive metadata regime. Its capabilities include collections, search facets, full-text search on the metadata. And since Koha’s version 3.22, the capability to directly host files linked to the bibliographic records. Basically it offers everything that 95% of Indian institutions look for when they are planning to setup a repository. Compared to DSpace, LIS professionals are already better acquainted with Koha (or as many in India like to call it – “KOHA” :-P) as it is the de-facto open source LMS. Further, by using Koha for hosting the repository, the institutions and professionals who are already using Koha as their LMS, gain one key advantage; they no longer need to maintain two separate and very dissimilar systems that use completely separate software application stacks (LAMP vs Java; MySQL vs PostgreSQL etc).

Step 1 – building a MARC21 ETD Framework

I had promised my colleagues to setup a demo ETD using Koha so that they could try it out. After all, there’s no better proof of the pudding than eating it. The first challenge to that is the while Koha does ship with quite a few MARC21 frameworks, an ETD framework is not one of them.

As my starting point, I turned to ETD-MS v1.1, which is considered to be something of a gold standard for ETDs. Taking the help of this page, I worked out a single paged worksheet for cataloging ETDs  on Koha. The result looked like this:

rawmarc

Step  2- Usability and maintainability

Of course this posed a slight problem, how will a cataloger accustomed to / trained on DSpace’s metadata namespace correctly do the crosswalk? To solve this in lines with Koha’s recommended Best Practices for UI mods, jQuery statements were included into Koha’s “intranetuserjs” and “intranetusercss” system preferences. The final outcome was this:

converted_marc

This approach has three (03) key benefits  – (a) that you DO NOT need to touch Koha’s Template::Toolkit based templates (i.e. the .tt files), the changes made are stored in your database and applied during runtime; (b) these changes remain persistent and works across Koha’s monthly version upgrade cycle (since we didn’t change the .tt files) and (c) our other MARC21 templates are left alone, only the ETD framework is thus modified.

The jquery snippet is available on Github as a gist, as is the CSS includes into intranetusercss system preference. There is also a third gist which lists the 04 authorised value categories and their constituent sample options that help us introduce a consistent controlled vocabulary in our metadata.

The demo ETD is available at http://etddemo-opac.l2c2.co.in/. If you wish to access the staff client back-end, contact me via the comments section of this post.

Best wishes!

Resources:

  1. http://blog.l2c2.co.in/wp-content/uploads/2016/06/export_ETD.ods
  2. https://gist.github.com/l2c2technologies/09e7e06f695304f33aada9b529167de6
  3. https://gist.github.com/l2c2technologies/9bc1f9b812e37850959c655fbc0f8802
  4. https://gist.github.com/l2c2technologies/6b735a5e1f4c4f9cc3042af2b8fa5b32
Licensing- CC 4.0 – BY-SA-NC – (c) L2C2 Technologies 2016

The Koha manual is your friend :-)

The Koha User Manual is an amazingly in-depth document that keeps getting better with each iteration, thanks to Koha Library System Project’s indefatigable Documentation Manager Nicole C. Engard. This post exemplifies a situation where it can come in handy.

Yesterday a librarian colleague reached out with a query. He is on Koha 3.20.x series and since the last 3 – 4 days, he had been noticing that the “due date” for items his staff was issuing out was coming out rather odd! For instance all the due dates were set to “18th June 2016“. He clarified that he did not have a hard due date set, so what is going on???

This morning he sent over a screen shot of the checkout operation. And boy! the date now read 25th-June-2016. This was an immediate clue! On checking out his calendar – 18th and 25th turned out to be the only two days that are marked as “library is open” in June 2016 (for issues made in these last two weeks i.e.  before the holidays begin) during their summer recess.

That holiday setting working together with the system preference “useDaysMode” set to “the calendar to push the due date to the next open day” for circulations was the reason why Koha was pushing the due date beyond the usual designated due dates for each patron category.  Basically, it was just Koha doing its job (as it was asked to do) and doing it well.

If you are on 3.20, remember to read up http://manual.koha-community.org/3.20/en/calholidays.html, the relevant system preference are all explained very nicely there by Nicole C. Engard, Koha’s indefatigable Documentation Manager.

Sending email alerts via GMAIL : a marriage of convenience or is it???

Library professionals using Koha ILS quite naturally want to send email alerts of circulation details, due date reminders, overdue notices etc to the patrons / users / customers of their libraries. Google’s GMAIL free email service seems to provide an alluring option:

  • gmail is *huge*! Everyone and their uncle is on gmail – resulting in almost instantaneous delivery of emails.
  • anti-virus, anti-spam facilities that are almost second to none.
  • and most importantly,  it is FREE (as in the proverbial lunch, supported by ads that google places on its web mail interface).

It is ridiculously easy to set up Postfix email server to use GMAIL to relay (i.e. send out the emails to the actual recipients) the email alerts generated by Koha. Endless tutorials exist online. Sounds like a perfect match! A Free Software ILS and a free email service, what could be better!

However, Google is a business entity and they are here to make money – for their shareholders, and over the years Google has been slowly cutting down on the number of emails you can send out in a day. If you hit the daily mail quota limits, Gmail will quietly disable email sending from your account for 24 hours. Do it too often, they may (and do) suspend your email account.

“A marriage of convenience, is neither a marriage nor a convenience!”

No, it won’t hit you at first when you are testing the setup or when you have low circulation figures. However, as you roll out and keep expanding services, the number of alerts you need to generate to provide an even more improved user experience, you are likely to end up hitting those quota. I kid you not!

We are switching to Let’s Encrypt as it exits public beta

Announcement!

Back in February this year, we had announced that we were switching on Let’s Encrypt SSL certificates on our servers and VMs on a trial basis. We are happy to share the news that with Let’s Encrypt finally getting out of beta stage, we are shifting to LE certs  for all our SSL support.

Why Let’s Encrypt?

From the LE website, some numbers:

 

Since our beta began in September 2015 we’ve issued more than 1.7 million certificates for more than 3.8 million websites. [..] We set out to encrypt 100% of the Web. We’re excited to be off to a strong start, and with so much support across the industry.

Why SSL is important to you?

By default, Koha’s OPAC and intranet sites use HTTP and *not* HTTPS. This means all data exchanged between your server and your visitor / patron / library staff accessing either of the sites over the Internet, goes over as plain clear text.

To give a real world analogy, this is like writing down your credit / debit card number, CVV / CVV2, expiry date on a postcard and posting it. Anyone that comes across the postcard while it goes from the sender to the recipient can read it. You are essentially broadcasting your user credentials to everyone on the Internet.

On the contrary, HTTPS encrypts all the data exchanged between the parties communicating. Only parties who can read the information thus encrypted is you and your user / visitor and no one else.

How does shifting to LE certs help our users?

Earlier we had to charge our users extra (INR 1200 to 2500 per year) for SSL support for their hosted OPAC and Koha ILS staff client. We were using SSL services of providers like PositiveSSL etc. However, LE’s objective is to bring affordable encryption to 100% of the world wide web – their certificate is FREE! So as our client-partner YOU get to enjoy (a) better value proposition (b) a well-supported quality SSL certificate with global recognition.

You may wonder why and how LE does this. This is what LE has to say about itself on it web site:

Let’s Encrypt is a free, automated, and open certificate authority brought to you by the Internet Security Research Group (ISRG). [..] ISRG’s mission is to reduce financial, technological, and education barriers to secure communication over the Internet.

The sponsors who have committed their support to make LE a success read like a who’s who of the modern Internet as we know it. It is also supported by American Library Association (ALA). So if you are a librarian, this endorsement will mean just how seriously LE is being taken! 😀

Even if you not a client-partner, but happen to follow this blog, we suggest that you seriously consider giving Let’s Encrypt a shot, if for nothing else for peace of mind.

Happy SSLing! 

Adding chat support to Koha

Yesterday being a lazy Sunday, I decided to tick off one of my pending TODO items i.e. watch the “Wishlist” discussion from National Koha Conclave organised by Informatics last February.

Around 34:30min into recording, Chris Cormack takes up the wishlist from ISI Kolkata. Around 35:19, Chris picks up the topic of chat facility that was on ISI Kolkata’s “wishlist”. He says that while it is unlikely that Koha itself would get one, it was really easy to integrate something like “MIBEW” and that all that is needed is someone to write up a HOWTO for that.

So, without further adieu, I decided setup a chat server on a dedicated sub-domain of l2c2.co.in. The idea being we should be able to use the chat facility across any servers and user accounts we managed on our servers spread out across the globe.

Installation proved to be a cakewalk on our Debian 8.x test server. We already had LAMP and mibew specific PHP extensions in place. Next up we installed nodejs, npm and gulp and finally we cloned the mibew git repo on Github. The deployment tarball was built following the instructions on the Github page.

Once ready, we unzipped the newly created mibew-2.1.0.tar.gz tarball into the DocumentRoot of the sub-domain we had created earlier. The instructions given in the README.txt proved to be adequate. First, we created the MySQL database, with required user and permissions. Setting the ‘cache‘ folder to writable by the webserver process was important. Next up, the database connection configuration went up into configs/config.yml which was templated off configs/default_config.yml.

Final setup was done by accessing http://<our-sub-domain_FQDN>/install.php and following the on-screen wizard. The admin user and password were setup and we were basically done. For the sake of security, the install.php was removed from the tree.

Logging in as the admin user, we setup a new group and added a new user to that group to work as an operator representing our client. The chat button code was copied over and pasted into the OpacNavRight system preference in Koha and saved all the changes made.

On the Mibew server side, things were just as simple. We logged in as user “brclibrarian” that we had created for Bhaktivedanta Research Centre. To make the user “brclibrarian” available for chat, we clicked on “Connect”.

Upon going “online” as brclibrarian user, the dashboard changed into an “inbox” page, where we now waited for our first support request.

Soon enough, a visitor on BRC OPAC had clicked on the chat button and we had our first support chat coming live at the “operator” side of things.

On the visitor’s side, the following screenshot shows the support chat in progress.

P.S. We wanted our chat button to say “Ask a Librarian“. So instead of using the default buttons that come with MIBEW, we used GIMP to quickly make a couple of images and saved them as aal_on.gif and aal_off.gif. The  “_on” and “_off” in the filenames is important. MIBEW reads the image name as “aal” with on and off markers treated as toggle.

To display when librarian / operator is absent.

To display when librarian / operator is online.

Sivanath Sastri College Library partners with L2C2 Technologies to take their library online

We are pleased to announce that Sivanath Sastri College, Kolkata, also known popularly as “South City Morning” has chosen to partner with L2C2 Technologies for taking their library online. Our thanks goes to the college authorities and the library Smt. Bhaswati Chattopadhyay for making this possible. The OPAC is live at http://ssclib-opac.l2c2.co.in.

About the Sivanath Sastri College

Sivanath Sastri College is a 55 year old undergraduate liberal arts college for women in South Kolkata (Calcutta). It is affiliated with the University of Calcutta. The name commemorates the legacy of Brahmo social reformer Sivanath Sastri.