Fakirchand College, West Bengal chooses L2C2 Technologies’ cloud hosting services for their OPAC.
We are happy to extend a warm welcome to our newest client-partner Fakir Chand College, located in Diamond Harbour, West Bengal. The library has a collection of more than 52,191 volumes. The library is divided into three broad sections – the UG, PG and the B.Ed sections.
L2C2 Technologies acknowledges with gratitude the co-operation extended by FC College. We would particularly like to thank Smt. Rekha Mondal, Librarian and Dr. Debashish Mitra, Bursar for their support.
About the college
Established in 1948, it is the oldest and largest college in South 24 Parganas district of West Bengal. Affiliated to the University of Calcutta, the college is named after Sri Fakir Chand Halder, the father of founder Sri Jagadish Chandra Haldar, a local businessman. It offers undergraduate courses in liberal arts, science and commerce, a teacher training course as well as a few post-graduate programs. The college is located at Diamond Harbours in the southern suburbs of Kolkata, on the eastern banks of the Hooghly River quite near where the river meets the Bay of Bengal. 
A quick-n-dirty way to remove the trailing dot from salutation field after a bulk patron import into Koha.
Earlier today the deputy librarian at our client partner Gouri Devi Institute of Medical Sciences and Hospital (GIMSH) called us wanting to figure out how to fix a small, but crucial problem. The employee list from GIMSH’s HR department was used to create the patron bulk import CSV  file. All 143 records got imported without a glitch and each individual records looked perfectly OK when viewing them. However, when she tried to edit these patron records, she noticed that the salutation (e.g. Mr, Mrs, Ms etc.) would not show up in the salutation drop-down during edit! 🙁
About 141 out of the total 143 records had a period “.” after the salutation and two didn’t. These two records which did not have the period at the end of salutation were displaying the stored value correctly in the drop-down, rather than showing as being blank. As it happens, Koha uses the BorrowersTitles system preference to store the options to display. The default options are Mr|Mrs|Miss|Ms. As you can see, none of these have a period at their end. So, while the salutation field value was stored in GIMSH’s borrowers table, it was not being displayed during the edit as the value didn’t match with the values stored in BorrowersTitles syspref.
***WARNING***The following step requires you to directly execute a SQL on the Koha database. This is usually not recommended, but some times, it is required to quickly fix a problem.
Using the TRIM() string function of MySQL in tandem with the specifier trailing  we can take out the “.” (period) at the end of the salutation from all the records in the borrowers table in the following manner:
UPDATE `borrowers` SET `title` = TRIM(TRAILING '.' FROM `title`);
 Sample patron data file – patron_import.csvNB. Those of you who wish to study how the HR data was prepared for import into Koha, can look here for a sample CSV file with dummy data (do not worry about privacy as the data is fake).
About Gouri Devi Institute of Medical Science and Hospital
Gouri Devi Institute of Medical Sciences & Hospital, Durgapur is a Medical College with ultra-modern 300-bed hospital setup by Rahul Foundation under the visionary stewardship of Mr. R. N. Majumdar. GIMSH welcomes new admission of 150 M.B.B.S. students in the academic session of 2016-17. The medical school comprises of 21 departments with experienced faculty members with extensive facilities that include well equipped classrooms, laboratories, an air conditioned library etc. The hospital is having all the clinical departments like General Medicine, General Surgery, Orthopedics, Ophthalmology (Eye), Otorhinolaryngology (ENT), Obstetrics & Gynecology (OBG), Dermatology, Pulmonology, Pediatrics, Psychiatry, Dental etc. including a full-fledged emergency & trauma care center. 
About the Library
The library is located on the 2nd floor of the college building with 1827 sq. m. of floor area that consists of the Stack room, Journal section, air-conditioned Students reading room, Staff reading room, Internet MEDLARS room, Audio-visual unit, Reprography room, Circulation counter, rooms for the Librarian and other staff, Daftaries and Book binders, Skill lab etc.
 Gouri Devi Institute of Medical Sciences and Hospital website
Choose the list of languages to transliterate on the Koha OPAC
Life sucks right?? 😉 But as long as it is still there, here’s “one for the road”! 😀 So, read on!
By default that provides us with this short language drop-down:
For users from India, a country with 22 official language at the last count, that default list is woefully too little, too less. The good news is that Google’s Transliteration API supports several dozens of languages. Which ones? Well you need to dig around LanguageCode and SupportedDestinationLanguages enumerations in the documentation.
Show me the money!
The code to support the function is loaded via googleindictransliteration.js file that resides under /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/js/ on a Debian package based installation.
The screen grab below shows exactly that changes we needed to make in order to show on Hindi and Bengali as the list of languages, *and* with Bengali as default language option on the select drop-down.
So how did I know that I needed to use “bn” for Bengali? Well, that LanguageCode enum list I’ve linked to above. Simple really!
One more fact about this tip that will bug a few
Change(s) to the LanguagesCode enum like this within the googleindictransliteration.js file would cause *all* instances on a multi-tenanted Koha installation to display the same list of languages. So, if you need different sets of languages lists in different OPACs, you are probably out of luck.
Either you know what you are doing or take time to learn or invest in quality support. Fail on all three counts and you are quite literally asking for an operational nightmare.
Recently a young colleague Sri Ashkar K. from Thiruvananthapuram, Kerala (India) ran into a problem. He works as a librarian with Mathrubhumi, a major media house from Kerala. Specifically he needed to have a LMS solution to efficiently manage their collection of entertainment (mostly movies) related CDs and DVDs. For him the LMS was hosted Koha. However when he tried to issue an item i.e. a movie CD, he was stumped by this error every time:
No branchcode argument passed to koha::Calender->new at /var/koha_all/mathrubhumi/lib/C4/Circulation.pm line 3558
Being on a hosted Koha platform, he approached his service provider for support. He shared with them all the relevant screenshots leading to error detailed above.
The provider’s tech support could not identify the issue and instead informed him that they could perform checkouts (issue) without any errors. As Ashkar persisted, the service provider’s support desk asked him to provide remote desktop sharing using Teamviewer so that they could see “his problem” in action. Installing Teamviewer needed clearance from his IT department which required time and thus Ashkar’s checkout problem continued to linger. Finally about 10 days back he posted about it on the official Facebook page of Koha Library System Project, asking for suggestions to resolve it.
The first flag was raised by fellow Koha dev Mark Tompsett when he asked:
“/var/koha_all/mathrubhumi/lib/C4/Circulation.pm” — That is not a standard installation path. How did you install this? And what version?
Ashkar replied that since the software was hosted, he did not know the installation details. This got my attention! If he was on hosted Koha, why was he turning to the community for support? What was his service provider doing in the first place? I decided to find out more. That’s when I discovered the details of his situation. Desperate for help, he provided me with superlibrarian access to his hosted Koha’s staff client interface. I logged in and found that the problem was very real. In fact, I found out a few rather *disturbing* things.
The hosted Mathrubhumi Koha instance wasn’t running on the stable version (which is 16.05.05 at the time of writing) of Koha ILS. In fact, it was running on an unstable development version (at the time of this writing it was using Koha 16.0600023). Development versions are not GA releases and are *never* meant for production use, they are meant for use by testers and developers. And secondly, I could not do a MARC21 export for his bibliographic data.
That set alarm bells ringing in my head and so with Ashkar’s approval, I created a backup of his Koha database and installed the backup on L2C2’s test server running the latest stable 16.05.x version.
The first clear indication of what was wrong came soon after running sudo koha-rebuild-zebra -v -f mathrubhumi successfully without any error. A wildcard search from both OPAC as well as the staff client failed to return a single result, even though the Zebra indexer and output logs showed no error. However, it was possible to access a record by directly accessing it by biblionumber.
Running the “MARC Bibliographic framework test” to check the MARC structure provided the answer. Sure enough there were two major errors as shown below:
homebranch NOT mapped
the items.homebranch field MUST :
be mapped to a MARC subfield,
the corresponding subfield MUST have “Authorized value” set to “branches”
holdingbranch NOT mapped
the items.holdingbranch field MUST :
be mapped to a MARC subfield,
the corresponding subfield MUST have “Authorized value” set to “branches”
The question now was to identify *which* MARC21 framework since he had three (03) of them.
Checking the “MOVIES” framework, it was found that both 952$a(homebranch) and $b(holdingbranch) were set to ignore in the Managed in tab dropdown. This explained the error displayed by “MARC Bibliographic framework test”. To know more about the the 952 MARC21 field in Koha, please read Holdings data fields (9xx) from the Koha community wiki.
It was a simple matter of setting both 952$a and $b to “items(10)” for the option Managed in tab. This took care of the “MARC Bibliographic framework test” error.
However, that was only the first part of the solution. Except two, none of his other 23 bibliographic records had their homebranch and holdingbranch defined. It was time for a batch item modification from the Tools page (Home > Tools). This has been covered in details in an earlier blog post – “Koha’s MARC modification templates comes to the rescue“, so if the topic sounds unfamiliar, it is suggested that you read that post first.
In order to find out all the barcodes that needed to be used to update the records, the following SQL report was used:
LEFT JOIN biblioitems ON (items.biblioitemnumber=biblioitems.biblioitemnumber)
LEFT JOIN biblio ON (biblioitems.biblionumber=biblio.biblionumber);
With the list of barcodes in hand, it was time for the final steps:
Load up barcodes for the records to be bulk modified
Select the two fields that we wanted to update – homebranch and holdingbranch
Select the actual branch option for both and click on Save
And we were done! 🙂
Understanding the error is quite simple if you know how circulation works inside Koha. A checkout operation needs to know a few basic things – (a) who owns the item; (b) where is the item presently located; (c) what to set as the issue and due dates and (d) who is taking it. Since the items attached to bibliographic records created using the MOVIES MARC21 framework did not have their homebranch and holdingbranch defined, at the time of checkout, as Koha tried to set the issue date and calculate the due date, using the date functions from the Koha::Calender object, it failed to do so. That’s what gave Ashkar his error and prevented him from checking out an item.
This still left one question unanswered – why did Ashkar’s hosting provider keep insisting that everything was working OK at their end and wanted him to provide them with Teamviewer access instead. My best guess is they were checking out the system using only the MARC21 frameworks which *they* had shipped i.e. default and fast add (FA) frameworks. Since records generated using these two frameworks (quite correctly) had 952 $a and $b set, none of these triggered Ashkar’s error during checkout. They certainly did not need Teamviewer access, the error in Ashkar’s framework should have been easily detected and quickly fixed. In fact, it took less than 3 mins to take care of it. But they failed, which is why it is important to either invest in your own skill development (read RTFM)OR invest in quality support.
“If you pay peanuts, you get monkeys” – James Goldsmith
Moral of the story: If you work with service providers whose front line tech-support is staffed with inexperienced people, be prepared for the long haul and self support yourself. Caveat Emptor!
Sammilani Mahavidyalaya (Kolkata), West Bengal chooses L2C2 Technologies’ Koha hosting services on the cloud.
We are pleased to welcome Sammilani Mahavidyalaya, Baghajatin, Kolkata to our growing family of client-partners in West Bengal. We look forward to working along with them in their quest to transform the library into a model library in the years ahead.
Established in 1996, Sammilani Mahavidyalaya is located in Baghajatin on Eastern Metropolitan Bypass, Kolkata. Initially the college started functioning from a local secondary school, Santoshpur Vidyamandir (Boys) and the classes were held in the evening. Within a record period of only seven months it’s new building was constructed and the college shifted to its present address. From a humble beginning with just 3 students, the college today caters to the educational need of nearly 2000 students spread across its Humanities, Science and Commerce departments. It is affiliated with the University of Calcutta.
West Goalpara College, Assam, chooses L2C2 Technologies’s hosted Koha platform with local support from Aditi Library Services.
We are happy to announce that Krishna Kanta Handique Central Library, West Goalpara College in the north eastern state of Assam have choosen to implement Koha ILS on our cloud service. They are currently hosted on the latest stable, packaged version of Koha i.e. 16.05.04. The local support will be provided by M/s Aditi Library Services – a known name among libraries in the North East.
Setup in 1981, the college is located at Balarbhita, in the Goalpara district of Assam. Affiliated with Gauhati University, Guwahati, Assam, in the last 35 years, the college has served the higher education needs of over 70,000 students. The college’s central library is named after Padma Bhusan Sri Krishnakanta Handique (also spelt as Handiqui), a great scholar and educationist who also served as the founder Vice Chancellor of Gauhati University. The library was established in 1987 and was inaugurated by Shri Prafulla Kumar Mahanta, then Chief Minister of Assam. The library has a collection of over 20,000 books covering various subjects as well as collections of journals, magazines and newspapers. Aside from the central library, the individual departments have their own departmental libraries for reference service. It is supported by Ministry for Development of North Eastern Region, Government of India.
Special mention has to made of Sri Hirak Jyoti Hazarika who was instrumental for bringing Koha ILS to the college. Sri Hazarika has since registered for PhD at NEHU (North East Hill University, Shillong, Meghalaya). We wish him every success in life.
Individual ‘lockdown’ of Koha’s system preference settings using a bit of jQuery and CSS.
The current stable version of Koha 16.05.4 ships with some 548 system preferences. These are stored in the ‘systempreferences‘ table in the database. Inside the Koha staff client, they are accessed by visiting the Home > Administration > Global system preferences menu link. If this is the first time you are hearing about system preferences in Koha or you are not deeply familiar with them, it is suggested that you familiarize yourself with this chapter section of the Koha 16.05 manual.
The objective here is not prevent someone’s use of Free Software, but rather to ensure they are only committing pre-validated changes to the production server. Changes have consequences and whoever makes them should be fully aware of the impact of these changes.
While Koha’s per user access control feature does provide a way to allow or withhold an user’s access to view / edit the system preferences, it does so with an “all or none” approach i.e. either the user has access to *all* the system preferences or none. This lack of access control granularity can prove to be slightly undesirable under certain circumstances. For example, you want that certain settings should *not* be changed or not changed accidentally or not changed without first testing and validating the change on a staging system. In our case, on our managed systems we do not want the designated superlibrarian user at the client’s end to make changes to say the opacheader, opaccredits, OPACUserJS, OPACUserCSS, IntranetUserJS, IntranetUserCSS and OpacNavBottom system preferences on the production VM, without first testing the changes on a test VM.
We implemented the setting specific ‘lockdown’ in the system preference settings using a bit of jQuery and CSS.
First we identified the selectors we needed in order to enable the lockdown. The easiest (and recommended) way to do this is to ‘inspect‘ your target (i.e. ones you want to lock down) DOM elements on the System Preference administration page(s). As mentioned before we want to lockdown the following sysprefs: IntranetUserJS, IntranetUserCSS, OPACUserJS, OPACUserCSS, opacheader, opaccredits, OpacNavBottom. Looking at the DOM made it clear that we needed to work with the following id based selectors – pref_IntranetUserJS, pref_IntranetUserCSS, pref_OPACUserJS, pref_OPACUserCSS, pref_opacheader, pref_opaccredits and pref_OpacNavBottom respectively.
The next step was to decide how tight we want to make the ‘lockdown’. We did not want it airtight, so here is what we did. We left the IntranetUserJS and IntranetUserCSS only disabled, but the rest we removed their respective textarea elements from the loaded DOM. Had we wanted things really tight, we could have do that same for the two disabled ones.
Note: Should you use .remove() on all the elements above instead of setting the attribute to disabled, then the only way to get access to them would be by directly editing the IntranetUserJS syspref’s value in the database.
We will also add hints to the label so that users can understand why they are not able to access the setting. See the green arrow on the left above for the code. Once done, save the IntranetUserJS syspref and exit. We are done.
Checking our work so far
Let us search for the OPACUserCSS system preference. We will see (as given below) that the editable textarea element is no longer present. Note the “Click to collapse” text without the editable textarea element holding the actual setting value. Also there is now a small lock icon against the label with the text explaining why the edit window is not present.
Unlocking the ‘lockdown’
What we have implemented so far will prevent someone with system preference edit permission from accidentally editing the ‘locked’ system preferences from the Admin page. In order to “unlock“, first we need to access the IntranetUserJS syspref which we had only disabled in this case.
Unlocking – Step #1
Right click on the IntranetUserJS syspref and select Inspect
If you did it correctly then element with id as pref_IntranetUserJS with be highlighted. Note the disabled attribute which is pointed to with the red arrow in the screenshot below:
Unlocking – Step #2
Double-click to select the disabled="disabled" attribute of the textarea element.
Unlocking – Step#3
Delete the disabled attribute, the textarea element should now look like this.
Unlocking – Step #4
Close the Developer tools window, but *do not* move out of the IntranetUserJS syspref yet! We still have work to do. You will see that the textarea is no longer disabled and is now open for editing. In order to remove the ‘lockdown’ on our system preferences, we need to comment out the jQuery code we had added earlier. We do this simply by wrapping the relevant code inside a C style /* [...] */ comment block. See the green arrows in the image below:
Unlocking – Step#5
Save the IntranetUserJS syspref and now try to access the OPACUserCSS syspref again. As you can see from the image below, the system preference is no longer locked and now open for editing.
Once we are done with making necessary changes we may wish to again ‘lockdown‘ the settings. We simply need to go back and edit the IntranetUserJS syspref and un-comment the locking code by removing the C style comment markers. Easy Peasy!
How to display custom content in the user’s own language on the OPAC.
Last week Mr. Ahmad Nasser from the Future University of Egypt reached out for a bit of help. The Koha OPAC provides certain sections / blocks on the OPAC e.g. OpacNav, OpacNavBottom, OpacNavBottom and OpacMainUserBlock etc. where libraries can add custom content / instructions / links / widgets to aid and inform their users better about their library and its services. Nasser’s case was interesting since he needed to cater to a bi-lingual readership where some users may prefer to read the information presented in Arabic rather than in English.
Development of language was the greatest break through of human technology. It helps us to communicate. But the same language when it is not the same for a group of people can create problem. How do a Bengali communicate with a Tamil, a Malayali with an Assamese when they do not understand the others’ language and they do not happen to speak English the global lingua-franca? Sort of like this line from this famous song pictured on Raj Kapoor in his super hit 1955 super hit – Shree 420 that goes “mera joota hain Japani, yeh patloon engleesthani, saar pe topi russi….” (‘My shoes are Japanese, these pants are from England, the red hat on my head is Russian…’) – indeed how do we cater to this diversity!
When it comes to a software like say Koha, the answer lies in localization – a process which allows a software to present information to its users in their own language of choice.
Nasser wanted a way to display the content of say OpacMainUserBlock in Arabic when the user switched the user interface to Arabic and back in English when another user wanted to use the default language (i.e. english). This post highlights one ways by which Koha administrators / librarians can let their users a way to see the content in the language of their choice rather than an arbitrary default language or even worse a mish-mash of two or more languages.
This case is relevant to libraries in India as well, with our multitude of languages – 22 official languages at the last count – How do we serve content in English to our top 10 – 15% population, at the same time how do we address the rest of our population who are literate in their own language, all who may be some day be using Koha. Our records may be in the local regional language, but how about the added custom content? This solution works by looking at present locale selected the user on the Koha OPAC.
As I’ve mentioned this is not the only way to solve this problem. But it is probably the simplest *and* the cleanest one. And it does so by using three things:
The selected locale language of the Koha OPAC
One line of custom CSS placed into OpacUserCSS system preference
In this blog post, we’re only looking at managing the OpacMainUserBlock – the central block on the OPAC, but the solution can be applied to every other blocks that access custom HTML markup – including OpacHeader, OpacCredits as well as on “Koha as CMS” pages etc.
I’ve set up a multiple language demo Koha installation with the following languages aside from the default English:
(a) Arabic (ar-Arab)
(b) Czech (cs-CZ)
(c) German (de-DE)
(d) Hindi (hi)
(e) Slovak (sk-SK)
(f) Chinese (Taiwanese: zh-Hans-TW)
The URL is https://demo-opac.l2c2academy.co.in/cgi-bin/koha/opac-main.pl where you can see this working in action. As you change the selected language and right click to see source code of the page, you will notice that the “lang” attribute of the “html” element changes to the language codes given inside the parentheses above. Below is a snapshot of 6 of the 7 languages as rendered in the HTML source once you change the language.
Hint: That lang attribute is our locale identifier and it changes every time we select a different language. Try it out on the demo and see it for yourself.
Since this depends on using CSS to toggle the visibility of our local language content we are going to define a disabled class in our OpacUserCSS system preference like this:
/* disabled class */
In this example we will use a <div> element like given below:
<div class="en disabled">
your local language content goes here
However we can use this technique on *any* HTML element whose visibility can be toggled by accessing its display CSS property . We will need to add two extra classes to our HTML element – the first one class will be named as our lang attribute and the second class will be the disabled class. We’ll need to repeat this definition for each language that we want to deal with.
For your reference here is a listing of my OpacMainUserBlock for this example, please download and study it in order to understand the process better.
NOTE: For this example, I’ve selected a single paragraph from the entry on “Wikipedia” from the Arabic, Czech, German, English, Hindi, Slovak and Chinese Wikipedia.
Once, our custom HTML is in place, we will need a way to toggle their visibility (CSS display property) based on the user selected language locale via the lang attribute. For this we’ll use the following JQuery snippet in our OpacUserJS system preference:
var selectedlang = $('html').lang;
var buildClassString = ".".concat(selectedlang);
The first line finds out the lang attribute of our <html> element. In the next line we build a string to hold the selector for the class (since classes are notified in JQuery selectors using a dot in front of the class name). And finally, in the third line, we remove the disabled class from the content whose language class matches the lang attribute. By removing the class from the element, we automatically cause its display CSS property to become visible.
What really happens behind the scenes
The custom HTML markup is first loaded with its visibility turned off. Once the page is loaded the document.ready() JQuery call looks up the current language selected and removes the display: none; CSS style from the element by removing the disabled class. As a result, the element and the content it is designated to display becomes visible. This whole cycle is repeated when we select another language. Thus, we are now able to provide our users with custom HTML markup and content based on the language they selected.