Monthly Archives: July 2010

Showing item type counts on the checkout screen

Does your library limit your patrons to a certain number of checkouts for certain item types? At the Athens County Public Libraries, for instance, we limit patrons to 10 audio books, 10 music CDs, 10 videos, and 5 DVDs at a time. If a patron tries to check out more than 5 DVDs, Koha will show a warning. But what if you want to be able to tell at a glance how many a patron has?

This functionality was available to us in our 2.x installation, but when we upgraded to 3.0 our support company at the time told us it wasn’t a customization they would support. This wasn’t a feature we were willing to give up, so I set out to duplicate it using the tools available to me: system preferences and JavaScript.

Information there for the taking

All the information we need can be found on the patron checkout screen, we just need to figure out how to get it. The page lists all the items checked out to the patron, and it shows the item type for each:

List of items checked out on the checkout screen

With this available to us we can use jQuery to count each instance of each item type. We need to build a count for each item type in our system, so the script isn’t very portable. It looks for table cells (“<td>“) containing the description of each of our item types:


var itypes = {'circ': 0, 'avid': 0, 'avbk': 0, 'avmu': 0, 'advd':0 };
$("#issuest td:contains('Circulating')").each(function(){
itypes["circ"]++;
});
$("#issuest td:contains('Videos')").each(function(){
itypes["avid"]++;
});
$("#issuest td:contains('DVDs')").each(function(){
itypes["advd"]++;
});
$("#issuest td:contains('Audio Books')").each(function(){
itypes["avbk"]++;
});
$("#issuest td:contains('Music CDs')").each(function(){
itypes["avmu"]++;
});

The script starts by setting up an array of all my item types (“circ,” “avid,” etc.) and giving each a value of zero. Then the script looks for instances of each item type description on the page,  “Circulating,” “Videos,” etc., using jQuery’s :contains selector. Each time it finds an instance of one of those text strings the script increments the count for that item type. At the end of the process the script will have the count for each item type.

Displaying the counts on the page

In order to show the item type counts on the page we need to lay some groundwork by adding some markup. I want to add the count information right after the “Checking out to…” heading, so I’ll find that element’s ID using FireBug and jQuery’s after() function:


$("#circ_circulation_issue label[for='barcode']").after( ... );

The HTML I’m going to add is the default state, so it shows a zero count for everything:


<p style="margin-top:1em">
<span id="avmuout">0</span> Music CDs out, <span id="avmuok">10</span> More Allowed
</p>
<p>
<span id="avbkout">0</span> Audio Books out, <span id="avbkok">10</span> More Allowed
</p>
<p>
<span id="avidout">0</span> Videos out, <span id="avidok">10</span> More Allowed
</p>
<p style="margin-bottom:1em">
<span id="advdout">0</span> DVDs out, <span id="advdok">5</span> More Allowed
</p>

I’ve  included unique IDs for the “count” spans so that I can easily update them with my script:


$("#avidout").html(String(itypes["avid"]));
$("#advdout").html(String(itypes["advd"]));
$("#avbkout").html(String(itypes["avbk"]));
$("#avmuout").html(String(itypes["avmu"]));

$("#avidok").html( 10 - itypes["avid"] );
$("#advdok").html( 5 - itypes["advd"] );
$("#avbkok").html( 10 - itypes["avbk"] );
$("#avmuok").html( 10 - itypes["avmu"] );

In the first of the two sections above I take the count I got earlier, itypes['avid'] and set the content of the corresponding <span> using the html() function. I also want to show how many more the patron can check out, so I subtract the count from the limits I’ve set in my Koha installation.

If you have patrons who have exceeded their checkout limit you’ll see a problem: The page will tell you they’re allowed to check out a negative number more items. We can correct the script to accommodate:


$("#avidok").html((10-itypes["avid"] &gt; 0) ? 10-itypes["avid"] : 0);
$("#advdok").html((5-itypes["advd"] &gt; 0) ? 5-itypes["advd"] : 0);
$("#avbkok").html((10-itypes["avbk"] &gt; 0) ? 10-itypes["avbk"] : 0);
$("#avmuok").html((10-itypes["avmu"] &gt; 0) ? 10-itypes["avmu"] : 0);

Final version

Here’s what the results look like:

The final version includes proper escaping of the HTML content and wraps the whole process into a function (“itemTypeCount”). This function will be called on page load only if jQuery finds that the table of checkouts, which has an ID “issuest” is being displayed. The whole script goes into Koha’s intranetuserjs system preference.


function itemTypeCount(){
$("#circ_circulation_issue label[for='barcode']").after("<p style="margin-top:1em" class="icount"><span id="avmuout">0</span> Music CDs out, <span id="avmuok">10</span> More Allowed</p> <p class="icount"><span id="avbkout">0</span> Audio Books out, <span id="avbkok">10</span> More Allowed</p> <p class="icount"><span id="avidout">0</span> Videos out, <span id="avidok">10</span> More Allowed</p> <p style="margin-bottom:1em" class="icount"><span id="advdout">0</span> DVDs out, <span id="advdok">5</span> More Allowed</p>");

var itypes = {'circ': 0, 'avid': 0, 'avbk': 0, 'avmu': 0, 'advd':0 };
$("#issuest td:contains('Circulating')").each(function(){
itypes["circ"]++;
});
$("#issuest td:contains('Videos')").each(function(){
itypes["avid"]++;
});
$("#issuest td:contains('DVD')").each(function(){
itypes["advd"]++;
});
$("#issuest td:contains('Audio Books')").each(function(){
itypes["avbk"]++;
});
$("#issuest td:contains('Music CDs')").each(function(){
itypes["avmu"]++;
});
$("#avidout").html(String(itypes["avid"]));
$("#advdout").html(String(itypes["advd"]));
$("#avbkout").html(String(itypes["avbk"]));
$("#avmuout").html(String(itypes["avmu"]));
$("#avidok").html((10-itypes["avid"] &gt; 0) ? 10-itypes["avid"] : 0);
$("#advdok").html((5-itypes["advd"] &gt; 0) ? 5-itypes["advd"] : 0);
$("#avbkok").html((10-itypes["avbk"] &gt; 0) ? 10-itypes["avbk"] : 0);
$("#avmuok").html((10-itypes["avmu"] &gt; 0) ? 10-itypes["avmu"] : 0);
}
$(document).ready(function(){
if(document.getElementById("issuest")){
itemTypeCount();
}
});

Caveats

This system works very well for my library, but it comes with a few caveats:

It requires that you hard-code, in the script, handling for each of your Koha item types.

Besides being tedious, it also requires that you modify the script each time you change your item types.

It requires that you hard-code the correct item type limits.

Also tedious, and requires that you modify the script each time you change your circulation rules.

It creates a potential collision with both call numbers and titles.

If my item type description is “DVD” and my call number includes the text “DVD” as well I’ll get an inaccurate count. If my item type description is “Audio Books” and a patron has checked out a print book entitled Audio Books for long trips I’ll get an inaccurate count.

For us the disadvantages are not unwieldy and the collision problem has never caused a problem. The advantage we get is being able to tell at a glance whether the patron is going to be able to check out that stack of DVDs or whether we need to ask them to put some back. Better to ask them to pick their favorites up front rather than after we’ve already checked out some of them.

Developing with branches

There was recently some discussion on the Koha mailing list about how “branches” fit into the development process. I replied with a description of how I use branches in my development process, and this post is an expansion of that.

In my discussion of Koha’s bug-reporting process I mentioned that a developer who wants to work on a bug will “accepts” a bug in Bugzilla before beginning work on it. There is a lot more to the developer’s workflow going on behind the scenes. I’ll describe what my process is.

When I first begin to work on fixing a bug, I create a “branch” in the git version control system. When I do so git creates a separate working copy of the main branch, “master.”  This copy is of the very latest version of Koha available. I create a separate branch for each distinct change I want to make to Koha. That change might be defined as a bug fix for a particular bug, or a new feature. The changes to each branch might include modifications to many different files, but the changes should all be related to that one subject.

It’s vitally important that I keep my branches clean and separate from each other because the Release Manager is relying on me to make it easy for him to apply and test my patches. If I submit a patch that covers more than one “subject,” that makes it all the more difficult to test it properly. If I introduce a bug to one aspect of my update, the whole patch may have to be rejected. Keeping things as simple as possible makes it easier for everyone.

To see how this looks in my workflow, here’s a selection of my current working branches:

ip-Bug-3125-IE-selects-2010-05-18
ip-Bug-4173-restricted-status-2010-03-18
ip-Bug-4901-Zotero-subtitles-2010-07-09
ip-hold-interface-test-2010-07-19
* master
ps-Bug-2307-calendar-i8n-2010-07-13
ps-Bug-2704-440-Display-2010-07-13
ps-Bug-2981-alternate-solution-2010-05-18
ps-Bug-3459-topissues-2010-06-29

When I first sit down to work I create a branch with a prefix “ip-” for “in progress,” give it a short title and bug number if I have one, and add the date I started working on it. You can see I might have quite a view branches in progress at a time. This might be because I’m working on a big update which is time-consuming, or it might mean I’m stumped about what the solution is.

Each time I sit down to do more work on a bug I switch to that branch, download the latest updates which have been submitted and approved on the master branch, and tell git to “rebase” my branch. The rebase process merges my changes with the latest updates. If there are any problems with the merge git will warn me and ask me to make manual changes. Usually the process is automatic. I do this every time I sit down to work on an in-progress branch. This ensures that the changes I’m making are compatible with the latest version of Koha.

Once I have finished my work I check it and test it as carefully as I can. I make sure I’ve rebased against the very latest update in git, and I submit a patch. Submitting a patch takes the changes I’ve made and distills them down to a single text file which can be “applied” by the Release Manager or any other Koha developer to their own git installations. I also attach a copy of my patch to the bug report, if there is one, as I described in my bug reporting post. This is another way to get the patch out into the open where others can review it and test it.

After I’ve submitted a patch I rename the branch I was working on with “ps-” for “patch sent” and keep the branch until my patch is approved (fingers-crossed).

All this is on my computer in a virtual machine, so in my case I’m not being open as I might. If I had the resources to work on a real server, or if I kept my work on a service like GitHub I could share all these branches with everyone, from the time I first started working on it to the time my patch was submitted.

If some time has passed and I see that my patch from one of my “patch sent” branches hasn’t been approved I’ll switch to that branch and rebase: I’ll tell git to grab the most recent Koha commits and merge them with the changes in my patch. If not too much time has passed, or the files I changed haven’t been worked on by others the rebase will be successful and I’ll know I’m still on track. If not I might have to manually make changes to my original commit so that it fits in again with the work others have been doing. If manually merging was required, that tells me the Release Manager would have to do the same. I should consider resubmitting a revised version of my patch which can apply cleanly to the latest version.

Keeping all my “patch sent” branches intact until my patch has been approved is important to my workflow because it’s the easiest way for me to keep track of what has been approved and what hasn’t. I can see at a glance which patches of mine have not been approved. If it’s been a while, I might try to find out why not. If there was a problem with the patch I might be able to revise it to the RM’s satisfaction.

I can’t submit a patch and expect it to automatically work a month from now, a week from now, or even a day from now. I’m responsible for keeping up.

I’m not a git expert, and I’ve had lots of help and advice along the way to get me to this workflow. It works really well for me, and I hope it works as well from the point of view of our Release Manager and fellow developers.

Customizing the staff client login logo: Addendum

I left something out of my post on Customizing the staff client login logo that I wanted to be sure to add: Once you’ve changed the logo you may want to change where it links to as well. By default it links to the Koha web site (or the deprecated version if your installation is an older one). We can use a little snippet of jQuery to change that link.

Using jQuery to change the URL to which the staff client logo links

$("#login h1 a").attr("href","https://www.myacpl.org");

That looks for an <a> tag inside an <h1> inside <div id="login">, which is specific enough to only catch the login form. This snippet goes inside your intranetuserjs system preference. Assuming the only thing you’ve added to intranetuserjs is the code I covered in the previous post, this would be the revised version:

$(document).ready(function(){
$(“#login h1 a”).attr(“href”,”https://www.myacpl.org”);
});
// ]]>


// <![CDATA[
//

Customizing the staff client login logo

A Koha user (from Tanzania!) asked today on the Koha mailing list, “I need some help on how to customize the staff client login page/replace koha logo with a new one.” I haven’t heard this request before, so it’s a good opportunity to investigate.

If this were the OPAC we could use a system preference, opacsmallimage, to change the logo. We don’t have that option in the staff client, so we’ll have to see if we can use the available customization options to accomplish the same thing.

Our first stop, as usual, is FireBug. I opened up the staff client to examine how the default Koha logo is displayed on the login form. Using the Inspect tool I highlight the logo and view the results in the FireBug HTML inspector window:

FireBug details for the login logo anchor tag

The logo is constructed by nesting a link (“anchor”) tag (<a>) inside a top-level heading tag (<h1>). The above screenshot shows the HTML and style details for the <a>, here are the results for the <h1>:

FireBug details for the login logo heading tag

From this we can collect all the CSS information we need to control the display of the login logo:

#login h1 a {
border-bottom:medium none;
display:block;
height:74px;
text-indent:-1000px;
}

#login h1 {
background:url("../../img/koha-logo.gif") no-repeat scroll center top transparent;
margin-bottom:0.5em;
margin-top:0;
}

The staff client logo is displayed using an image-replacement technique similar to the one used to display the Koha logo in the OPAC. The style of the anchor tag sets an explicit height which matches the logo image, and it sets a negative text-indent property which moves the text contents of the tag off the screen. These two properties create a blank space inside the anchor tag in which to display the logo.

The style of the heading tag does the work of displaying the logo. The background property points to the URL of the logo image. In the default case this is an image file on the Koha server’s file system. The URL doesn’t have to be a relative one, though. It can be a full URL pointing to anywhere on the internet.

Customizing the logo CSS

In order to change the image we need to make very simple changes to two CSS properties:

  1. The background-image of the <h1> tag.
  2. The height of the <a> tag.

Let’s use as an example the logo on the Athens County Public Libraries site. I can right-click the image in Firefox and choose “View image” to find the details I need. The location bar shows the URL I need, and the title bar shows the dimensions of the image. I just need to note the height.

Since we only need to change two properties, our custom CSS is simpler than the original. We only need to specify the properties which we need to override:

#login h1 a {
height:71px;
}

#login h1 {
background:url("https://www.myacpl.org/sites/all/themes/npl/logo.png") no-repeat scroll center top transparent;
}

Applying the custom CSS

We’ve got our custom CSS, now what do we do with it? We don’t have an opacsmallimage preference for the staff client, and we don’t even have an option like OPACUserCSS. We do have a couple of options which will work.

intranetcolorstylesheet

If you have access to your Koha server’s file system you can add a stylesheet there and tell Koha to apply it in addition to the default staff client stylesheet. For example, you could create a new CSS file called custom.css and save it alongside staff-global.css and the other staff client CSS files. Then you can specify that filename, custom.css, in the intranetcolorstylesheet system preference.

intranetuserjs

If you don’t have access to your Koha server’s file system, there’s a way to insert custom CSS into your staff client pages, but it’s a bit of a hack. Lacking an “intranetusercss” preference we’re going to hijack an existing preference, intranetuserjs, to do the job for us.

When you insert custom JavaScript into the intranetuserjs preference, Koha detects this and adds it to the header of each staff client page, wrapped in the appropriate <script> tags:


// 


Since Koha automatically wraps the intranetuserjs content in opening and closing <script> tags, we’ll have to do a little bit of roundabout coding to embed a <style> block:


//


/* Custom styles here */


// 

Let’s run down what’s happening here. Lines 1 and 2 have been inserted automatically by Koha in order to properly embed the custom JavaScript it expects from the intranetuserjs preference. Line 3 is the first line of the contents of intranetuserjs. Lines 4 and 5 we have added manually to close the automatically-embedded <script> tag. With the script tag closed we can go on to add just about any HTML we want, really, but this is all inside the <head> of the HTML document, so few things would be valid.

Lines 6, 7, and 8 show the <style> tag we’re adding. This is where we’re going to put our custom CSS. Lines 9, 10, and 11 are the last lines of our custom intranetuserjs. Knowing that Koha wants to close the <script> tag it opened on line 1, we have to re-open a new <script> tag so that when Koha closes it we’ll have valid markup.

Putting it all together, here’s what the contents of our intranetuserjs preference will be:

// ]]>



/* Custom styles here */
#login h1 a {
height:71px;
}
#login h1 {
background:url("https://www.example.com/images/logo.png") no-repeat scroll center top transparent;
}


// <![CDATA[

If all goes well, this is what you should see when you log out and look at your login screen:

id=”attachment_633″ align=”aligncenter” width=”300″ caption=”Customized login form”

Note: I’ve published a quick addendum to this post which covers using jQuery to change the URL to which the logo links

Interface test: Placing a quick hold

I was thinking about ease of use, and what we could to to improve the Koha OPAC from the point of view of the patrons, and the first thing my mind jumped to was the process of placing holds. For many patrons placing a hold is the goal of their visit to the OPAC. They’re looking for something they want, they find it in the catalog, and they want to get it. On Amazon.com the next step would be to buy it. In the OPAC they can place a hold.

What’s the first thing they see when they click one of those “place hold” links? Potentially this:

Place hold interface with all options turned on

I hate it. It’s an ugly table with too many options. True, you can turn off some of those options for a simpler process. Turn off the OPACItemHolds system preference to eliminate the option of choosing a specific copy. Turn off OPACAllowHoldDateInFuture to hide the Hold Starts on Date column. Turn off OPACDisplayRequestPriority to hide the hold request’s rank in the queue. Now it’s a little simpler:

With optional settings turned off

I’m still not crazy about it, and that’s why holds came to mind when I thought about what we could do to improve interactions in Koha. How can we make that interaction simpler? How about [almost] one-click “ordering?”

Click the "Place hold" link in the right sidebar

When you click the “Place hold” link you can see my idea demonstrated. Clicking the link would use JavaScript to display a simple form: Place hold? Yes/No. Embedded in the HTML would be all the required form fields, hidden, for placing a single hold with no options set, using the patron’s home library as the destination for the hold. If the patron wanted to set additional options they could click the “more options” link and be taken to the standard form.

How hard would this be to implement? It depends how far you want to take it. I could see  this being a JavaScript-only enhancement, assuming all the information we need is found on this page. In this version clicking the “Yes” button would submit the form to the same script the standard form does, but bypass the hold confirmation screen. The user would be redirected to their summary page showing current holds.

A fancier version would submit the form in the background. Clicking the “Yes” button would triggers a sequence of events:

  1. The hold would be submitted in the background.
  2. The interface would display some kind of “Working” indicator.
  3. Upon completion of the background submission, the interface would indicate success.

This is more complicated because the reserve script would have to be modified to work in new way. Error-handling would have to be incorporated so that if for some reason the hold couldn’t be processed the user could be warned. The advantage to this interaction is that the user never leaves the page, making it easier for them to find their way back to their original search–something which, incidentally, is also on our to-do list of ways to make things easier for the user.