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 😉

Generate a single sheet custom MARC21 framework in 2 minutes

For intermediate Koha ILS users who wish to quickly generate a single tab MARC framework.

Last Thursday, Ashish Kumar Barik, librarian at our new client-partner Midnapore City College filed a support ticket asking for a custom single sheet MARC21 framework or what is more commonly referred to by LIS professionals as a “worksheet“. He wrote that he wanted the following tags 000, 003, 005, 008, 020, 040, 041, 044, 082, 100, 245, 250, 260, 300, 440, 490, 500, 504, 650, 700, 942 and that the sub-tags/fields should be set as in the default marc framework shipped with Koha. We promised him his new framework. Being new to this side of Koha, he of course had missed out two key fields without which his system would be rendered practically useless i.e. the two local use tags952 and 999. Koha uses 952 to handle holdings (item) information and 999 is purely an internal tag used to track the bibliographic records.

Now anyone who has ever setup a new MARC framework knows that it can be a laborious and time consuming task. Further, there are chances of introducing inadvertent human errors that may lead to error or bad data when used as a part of the framework. As a result, at L2C2 Technologies we have developed several well defined strategies to manage custom marc frameworks for our clients. In today’s blog, we are going to share the simplest of the techniques we use in cases like this. The outcome of this exercise is a 100% error free marc framework generated in less than 2 minutes.

LEGAL DISCLAIMER: The next steps involve directly accessing and making changes in the the Koha database. So use these instructions at your own risk, if you face any data loss, corruption or system errors we are not responsible.

The Steps

  1. We used a regex capable editor like Notepad++ to quote the fields mentioned by Ashish, so that 000, 003, 005, 008, 020, 040, 041, 044, 082, 100, 245, 250, 260, 300, 440, 490, 500, 504, 650, 700, 942 became ‘000’, ‘003’, ‘005’, ‘008’, ‘020’, ‘040’, ‘041’, ‘044’, ‘082’, ‘100’, ‘245’, ‘250’, ‘260’, ‘300’, ‘440’, ‘490’, ‘500’, ‘504’, ‘650’, ‘700’, ‘942’. And while we did that, we also added the following fields missing in his list i.e. ‘952’, ‘999’.
  2. Next we defined a new framework MCC1 (MCC Framework) by visiting Home -> Administration -> MARC bibliographic framework -> New Framework
  3. Next we copied the default framework into MCC1 as its base, since that is what Ashish had wanted. At this point, the MCC1 framework is exactly same as the default framework of Koha.
  4. Next we fired up the MySQL console and logged in with the user id and passwd from MCC’s koha-conf.xml, and chose Ashish’s database in this case koha_mcc for the next steps.
  5. Fired the following SQL query :
    UPDATE
       `marc_subfield_structure` 
    SET
       tab=0
    WHERE 
       `frameworkcode`='MCC1' 
    AND 
       `tagfield` IN ('000', '003', '005', '008', '020', '040', '041', '044', '082', '100', '245', '250', '260', '300', '440', '490', '500', '504', '650', '700', '942')
    AND
       `tab`!=0;

    MySQL client told us 152 rows were affected.

    EXPLANATION: This moved all 1XX to 9XX (except 952 and 999) marc fields into Tab 0. The images below help illustrate the condition after this step:

  6. The next step was to set the rest of the fields outside the list supplied by Ashish *plus* 952 and 999 to be ‘ignored’ by Koha when using the MCC1 framework. And thus the following SQL query:
    UPDATE 
        `marc_subfield_structure` 
    SET 
        `tab`='-1' 
    WHERE
        `frameworkcode`='MCC1'
    AND 
        `tagfield` NOT IN ('000', '003', '005', '008', '020', '040', '041', '044', '082', '100', '245', '250', '260', '300', '440', '490', '500', '504', '650', '700', '942', '952', '999') 
    AND
        `tab`!=0;

    This time MySQL reported that 3416 rows were updated.

  7. Our last step at the MySQL command line was the following query that removed the unwanted 0XX fields from Tab 0 :
    UPDATE 
        `marc_subfield_structure` 
    SET 
        `tab`='-1' 
    WHERE
        `frameworkcode`='MCC1'
    AND 
        `tagfield` NOT IN ('000', '003', '005', '008', '020', '040', '041', '044', '082', '100', '245', '250', '260', '300', '440', '490', '500', '504', '650', '700', '942', '952', '999');

    MySQL reported 341 rows were affected.

  8. Coming back to MCC’s Koha staff client, we did the most important thing i.e. running MARC Bibliographic framework test. The test came out clean without any error.
  9. That’s it! MCC’s custom MARC framework is ready for use. Click on the image below and then zoom in to see the details up close.

Ramakrishna Sarada Mission Vivekananda Vidyabhavan moves to L2C2’s cloud based Koha platform

We are happy to announce that after nearly 2 years of being an L2C2 Technologies client-partner Ramakrishna Sarada Mission Vivekananda Vidyabhaban (RKSMVV) have decided to move entirely to L2C2’s cloud based Koha hosting platform from the academic session of 2018-19. The college had so far hosted their OPAC with us while running their day to day operations on a local system running a very old Koha 3.08.4. This is a major jump from them since they will by upgrading directly to 17.11 (the latest stable version of Koha) from a version that is nearly 6 years old.

About RKSMVV

Ramakrishna Sarada Mission Vivekananda Vidyabhavan is a partly residential degree college for women affiliated with the West Bengal State University, India. Colloquially more commonly known as “Sarada Mission College” or simply as “Sarada College”, it was the first educational institution started by Ramakrishna Sarada Mission. It came into existence in 1961 as an effort to carry out Swami Vivekananda’s ideals of education among women. Housed initially in a one-roomed makeshift structure, with thirty one students and a handful of young, idealistic and enthusiastic teachers and monastic members, the college today stands among the premier women’s institutions of the state with an ‘A’ Level by National Assessment and Accreditation Council

(Source: Wikipedia)

About L2C2 Technologies

Based out of Kolkata, India, L2C2 Technologies is an active Koha developer and library technology service provider.

Displaying unique title and volume count on the Koha staff client – Part 2

In this followup to our previous post on upgrade-friendly way of displaying unique title and copies’ count on the staff client, we explore a few variant use-cases reported by our readers.

Last December when we posted about the nifty little trick of displaying unique title and volume count on the Koha staff client, we didn’t realize that so many people would find something to be so useful. We received quite a few comments from all over the world. In this post, we are going to try and look at some of these use-cases that people thought could use something like this. So, if you are reading this and haven’t read the original post, it may be helpful to read Part 1 first.

The questions we received were:

(a) what if we have multiple branches?
(b) How to show the stats for the user’s logged in branch only?
(c) How do we show the overall totals if we have multiple branches?

Recently, the library at Our Lady Queen of the Mission School, Salt Lake had started to catalog both their junior library as well as the senior library. So, they presented the perfect opportunity to showcase these 3 use-cases.

1. What if we have multiple branches?

This was a question that came from Hussein Al-Nasri from Egypt. Hussein had tried the code snippet, but since it was hard-coded to handle only one single branch (the first on in the list of the JSON data returned), it wasn’t showing him what he wanted – the data for each of his branches.

The solution
$(document).ready(function() {
  if ( $('#main_intranet-main').length ) {
  $.getJSON("https://qmsl-staff.l2c2.co.in/cgi-bin/koha/svc/report?id=1&annotated=1.", function(data) {
    if ( data.length ) {
      $('#news1').prepend('<div class="newsitem" id="mystats"><table class="table table-striped" style="width: 100%; background: none;"><thead><th colspan="3" style="text-align: center; font-weight: bold; padding: 8px; line-height: 1.42857143; vertical-align: middle; text-transform: uppercase;">Library Statistics</thead><tbody><tr id="mystatstb"><td><strong>Branch</strong></td><td><strong>Unique titles</strong></td><td><strong>Total Copies</strong></td></tr></tbody></table></div>');
      for ( var key in data ) {
        $('<tr id=\"tr'+ key + '"><td class="text-center">' + data[key].homebranch + '</td><td class="text-center">' + data[key].bibs + '</td><td class="text-center">' + data[key].items + '</td></tr>').insertAfter( $( '#mystatstb' ) );
      }
    }
  });
  }
});

2. How to show stats only for the logged in branch?

This came from Freddy Enrique Pelayo from Peru, South America. He left a comment on the blog post asking:

if the system were to have more than 2 branches, will the screen show information according to the branch the user logged in?

The solution
$(document).ready(function() {
  if ( $('#main_intranet-main').length ) {
  $.getJSON("https://qmsl-staff.l2c2.co.in/cgi-bin/koha/svc/report?id=1&annotated=1.", function(data) {
    if ( data.length ) {
      $('#news1').prepend('<div class="newsitem" id="mystats"><table class="table table-striped" style="width: 100%; background: none;"><thead><th colspan="3" style="text-align: center; font-weight: bold; padding: 8px; line-height: 1.42857143; vertical-align: middle; text-transform: uppercase;">Library Statistics</thead><tbody><tr id="mystatstb"><td><strong>Branch</strong></td><td><strong>Unique titles</strong></td><td><strong>Total Copies</strong></td></tr></tbody></table></div>');
      for ( var key in data ) {
        if ( $('#logged-in-branch-code').html() == data[key].homebranch ) {
          $('<tr id=\"tr'+ key + '"><td class="text-center">' + data[key].homebranch + '</td><td class="text-center">' + data[key].bibs + '</td><td class="text-center">' + data[key].items + '</td></tr>').insertAfter( $( '#mystatstb' ) );
        }
      }
    }
  });
  }
});

Explanation

The key line here is $('#logged-in-branch-code').html() == data[key].homebranch. Whenever an user logs into the Koha staff client, the hidden <span> element with the id logged-in-branch-code holds the code for the user’s logged in branch. In the above snippet, we simply introduce a check to see if the code matches the homebranch code in the JSON array. If it does, we show the value for that branch and not for the other branches.

3. How to show the total for all branches?

This scenario was pointed to by Dr. Apurba Jyoti Mazumdar, Assistant Librarian, Assam Univerity, Silchar, India.

The solution

$(document).ready(function() {
    if ( $('#main_intranet-main').length ) {
    $.getJSON("https://qmsl-staff.l2c2.co.in/cgi-bin/koha/svc/report?id=1&annotated=1.", function(data) {
        if ( data.length ) {
            $('#news1').prepend('<div class="newsitem" id="mystats"><table class="table table-striped" style="width: 100%; background: none;"><thead><th colspan="3" style="text-align: center; font-weight: bold; padding: 8px; line-height: 1.42857143; vertical-align: middle; text-transform: uppercase;">Library Statistics</thead><tbody><tr id="mystatstb"><td><strong>Branch</strong></td><td><strong>Unique titles</strong></td><td><strong>Total Copies</strong></td></tr></tbody></table></div>');
            var totalbibs = 0;
            var totalitems = 0;
            for ( var key in data ) {
                $('<tr id=\"tr'+ key + '"><td class="text-center">' + data[key].homebranch + '</td><td class="text-center">' + data[key].bibs + '</td><td class="text-center">' + data[key].items + '</td></tr>').insertAfter( $( '#mystatstb' ) );
                 totalbibs = totalbibs + parseInt(data[key].bibs);
                 totalitems = totalitems +  parseInt(data[key].items); 
            }
            $( '<tr><td><strong>TOTAL</strong></td><td class="text-center"><strong>' + totalbibs + '</strong></td><td  class="text-center"><strong>' + totalitems + '</strong></td></tr>' ).insertAfter(  $('#mystats tr:last')  ); 
        }
    });
    }
});

Conclusion

As you may have noticed, in this version, we added an extra check which ensured that we only display this grid of data *only if* any data is returned. We hope that by answering a few of your questions, this post is of some use to some of you.

Quicktip – Ordering the display of your custom patron fields

An easy-peasy way to order the display of Koha’s ExtendedPatronAttributes fields.

This is going to be a brief tutorial, ExtendedPatronAttributes provide the capability to add custom fields to Koha’s patron management e.g. if we wish to capture say Program enrolled or Roll No. or other demographic details that we may be required to maintain under (a) law of the land or (b) governing rules of our library, this feature of Koha is friend we need to take help of.

If you have just landed on this blog and have no idea what we are talking about, we suggest that you may like to first read this earlier post – Harnessing Koha’s ExtendedPatronAttributes (aka patron custom fields). And while you are here, you may also like to visit this article.

Ok! Enough backstory, now back on topic! 🙂 When we define new custom fields to Koha using Home › Administration › Patron attribute types, the key thing to remember here is that these are ordered and displayed using alphabetic ascending sorting order of the defined Patron attribute type code.

Which means, when we defined a list of custom fields to capture student registration details e.g. as given in the screenshot below, we want them to be displayed in the order of the codes are numbered in the blue circles i.e. Student code, Registration No. and Roll No. in that order respectively.

Instead what we get is this:

The Solution

We simply need to number our codes. The way to do this is simply to prefix them with a serial number. Here we chose to use 00_, 01_, 02_”. Of course, this also meant that we had to dump off our old codes and put in these as replacement.

Hint: Do this before you start using the defined fields while entering your patron records. While it can be done later, you need to know what you are doing if you don’t want to mess up your patron data.

You can see what we did below:

And as you can see below, we have the fields displayed exactly in the order we had wanted in the first place.

A knotty problem – an Arabic catalog that refused to work in Koha 17.11

Watching out for custom developed themes during Koha upgradation will save you a lot of grief.

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.

– Sherlock Holmes [by Arthor Conan Doyle]

Early last week my good friend Vimal Kumar Vazaphally asked me if he could connect me to a friend of his who was facing some trouble after migrating to Koha 17.11 from 3.18. I agreed to take a look, since the problems that Vimal sends my way from time to time are usually interesting rather than mundane. Soon I was talking to Hussain (‎حسين رضوي‎) who manages the systems at the Public Library of Imam Hussain (AS) Holy Shrine, at Bab Alqibla, Karbala, Iraq.

The problem

Hussain informed that things used to be fine in the older 3.18 system, but after migrating to 17.11, they could no longer use the cataloging editor properly as the value builder for 008 MARC21 tag i.e. Fixed-Length Data Elements-General Information was not being displayed properly anymore, and the data being pushed back was the default value.

The chase begins

After looking at his system over Teamviewer and not making much headway, I asked Hussain to send over a copy of his database and went to bed.

By next day he had sent over his 1.2 GB database. I had it hoisted up on a test 17.11.01 system we have around, the same one which we had used the week before to migrate Bangabasi College from their earlier Koha 3.14.06. Since it was a multi-tenanted setup I could see the staged Bangabasi catalog working OK in it. Once the zebra reindexing has been done, our sleuthing started, we were able to reproduce the error.

The steps to the Truth

The first thing to check was for MARC framework validation – Ok! that was clean. Next up – detailed manual check of the framework in use. But everything looked shipshape. So what we had here was a curious beast. Since we were on a multi-tenant system and one was working just fine, the problem therefore had to be coming up from somewhere in Hussain’s database. But from what exactly was the question. When I mentioned about it on #koha (the IRC channel of Koha ILS), @wizzyrea (Liz Rea from CatalystIT) said that the issue sounded familiar and asked me to check whether it was bug no. 19473. It was not. However, 19473 looked interested so I added myself to the bug for tracking its status in future, and as I did bugzilla prompted – “The next bug in your list is bug 19965”

Bug no. 19965 turned out to be Hussain’s bug which he had reported on the Koha bug tracking database on 12th Jan 2018. This was from before we had connected. As I read through the comments on the bug by @cait – Katrin Fischer our indomitable QA lead, and incidentally visiting India at the moment for LTC2018 in Goa, I had my light bulb moment! 😉 I ran the 008 value builder and checked the JavaScript console. Firefox gave some hint that there was something wrong, but it was Google Chrome that showed exactly what was wrong.

Apparently, we had a 404 (file not found) error for marc21_field_088.xml. Now this was the file that Koha uses to load the list of values possible in the 008 field. This is what drives the drop-downs in the 008 value builder. I knew that we certainly had the file on the system, which is why things had worked for Bangabasi. The error message showed that somehow Koha was looking for the marc21_field_088.xml at a different location – intranet-tmpl/imam/en/data/marc21_field_008.xml rather than where it should intranet-tmpl/prog/en/data/marc21_field_008.xml.

The story was clear – this Koha installation had a custom staff client theme / template installed with the name of imam. So now we checked the template system preference under “Staff client” of Administration -> System preferences. But no the system preference showed only prog as the solitary value. Knowing that rhe staff client system preferences values are principally driven via a YAML file inside Koha called staff_client.pref, I decided to go for the source, in other words – the database itself.

A simple query :

SELECT * FROM `systempreferences` WHERE variable = "template"

showed what I had suspected, the actual value was set to “imam“. Another line of SQL later

UPDATE `systempreferences` SET value = "prog" WHERE variable = "template"

I was ready to test it. And Voila! there was it was… all working again! 😀

An explanation and an update

Now, you may be wondering why did Koha show the system preference template as only “prog” while its actual value was set to “imam”… is that not a bug? Well, not really! The value in the database is supposed to be one from the possible values in the YAML code for that system preference. So when you actually add a different value into the database and do not update the value in the YAML script, this is the expected fallback behavior.

You may also wonder so what happened to the bug no 19965 that Hussain had filed in the Koha bugzilla. Since, I had been able to verify that this was not a Koha bug, rather a user infused data error, I closed the bug report with the status – “RESOLVED-INVALID” along with this comment.

For Hussain, the first level solution was to update his database and point the installation to use the “prog” staff client theme / template rather than “imam”. At the secondary level, he had to port his old 3.18 theme – “imam” over to 17.11, which is quite likely to be a non-trivial exercise, should he / the library authority choose to do that.

Quick Tip – What to avoid when adding news items to your Koha OPAC

Avoiding common errors while using Koha – setting the library name correctly for news.

The News tool available in the Home -> Tools -> Additional tools section of the Koha staff client allows us to publish news and updates across – (a) OPACs (b) staff client and (c) printed slips generated by the library.

Being a handy way to publish library related updates, librarians like to use it. However, there are a few things that we need to keep in mind when doing this. For starters, we should not be logged in into the staff client as Koha’s database administrator; we must be logged in either as a superlibrarian OR as a library staff user with access rights to the News tool. The next thing to understand is even more important – the “Display location” and “Library” drop-downs.

Earlier today, we received a ticket on our online helpdesk –

“We have written a new notice but nothing is displayed on the opac.”

When we cross-checked, we found that to be true. So we checked the new notice to find out what may be the problem. And sure enough it was exactly what we had expected had happened. The notice / news was set to display on the OPAC of client-partner’s defined library branch, instead of being set to “All libraries”.

Now you may ask how can this be wrong??? Well, up until an user logs in via the OPAC, the “library (branch)” is *NOT* set as Koha has no way of knowing which branch (since a Koha instance can cater to multiple library branches of an organisation) of the library the user is looking at at the moment. The notices / news would have showed up *if* the user had logged in into *that* defined branch in this case.

So, the logic to keep in mind while publishing a news item on the OPAC – select a specific branch for display *ONLY* if you want the notice to be branch specific, otherwise, keep it generic as “All libraries”.

Once this was corrected, the news defined showed up just fine as can be seen below.

New and improved SLA management from L2C2 Technologies

Adding weekly SLA Management Reports for our hosted accounts of Koha ILS.

Starting this January, on every Monday (first day of the week for us) we will be mailing out weekly service level management reports and updates to our hosted Koha ILS client partners. We already have phone calls and the online support helpdesk covered and are now trying to figure out how to manage the instant messaging requests via Whatsapp, Telegram, Twitter and FB Messanger etc.

While the LIS professionals working with us from our client partners’ side already know where they stand with their SLA status, often the management is not fully aware of the work being done. With this new initiative we hope for greater transparency in our communication with our clients. Enclosed below are sample of these reports with the contact details reducted.

Koha ILS workshop at ICAR-NAARM, Hyderabad, Feb 5 – 9, 2018.

Indranil Das Gupta, Co-Founder, L2C2 Technologies will conduct sessions at the upcoming ICAR-NAARM organised Koha workshop.

Indranil Das Gupta, Co-Founder, L2C2 Technologies has been invited by ICAR-NAARM as resource person and faculty at ICAR-NAARM’s upcoming Koha ILS workshop in Hyderabad, India.

About the program

The ICAR – National Academy of Agricultural Research Management (NAARM) is organizing a training programme on Koha for library staff of ICAR during February 5-9, 2018. Dr. S.K. Soam, Head, ICM Division, NAARM and Dr. N. Srinivasa Rao, Principal Scientist are the programme directors for this training. They are expecting about 35 librarians to participate from various ICAR institutes in this training programme

About ICAR NAARM

The National Academy of Agricultural Research Management (NAARM) is a national-level research center located in Hyderabad, Telangana, India. It was established by the Indian Council of Agricultural Research (ICAR) in 1976, to address issues related to agricultural research and education management, in India. In the initial years, the Academy primarily imparted foundation training to the new entrants of the Agricultural Research Service of ICAR.

Subsequently, its role expanded to include research, capacity building of senior professionals of national and international NARS in agricultural research and education management, and policy and consultancy support to NARS. The Academy also renders services for building IP portfolios like patents and geographical indications to various stakeholders including farmers and scientists.

About L2C2 Technologies

L2C2 Technologies is a leading member of the global Koha developer community from India. Aside from upstream contribution, L2C2 Technologies have been active in the global Koha Release team for version 3.22, 16.05, 16.11 and 17.05. L2C2 started cloud hosting of Koha ILS in eastern India and have to its credit the first fully hosted Koha ILS having passed NAAC inspection in entire eastern India. We collaborate globally with people who write and publish Koha ILS software, thus ensuring international quality support while always being at the forefront of latest Koha development.​

[FOR IMMEDIATE RELEASE]