Quantcast
Channel: Koha Tips and Tricks – ByWater Solutions – Koha Open Source ILS Support
Viewing all 208 articles
Browse latest View live

Free RDA Cataloging Training Guide

$
0
0

Marielle Veve, Metadata Librarian at University of North Florida, recently shared a free RDA Cataloging Training Guide via one of the mailing lists I subscribe to.

I created this RDA manual for practical training purposes, is hosted in an institutional repository. It covers MARC cataloging for print books and e-books using RDA. Is in PdF and has a Table of contents for easy navigation, (may take some time to download, but is Free!).

I’ve noticed a lot more tickets coming in to us about RDA and so I thought that this might be of use to some of our partners.

The post Free RDA Cataloging Training Guide by appeared first on ByWater Solutions - Koha Open Source ILS Support.


Playing in the Koha sandbox

$
0
0

Have you ever been browsing through the Koha bugs database and see a bug with a status of “needs sign off”? Have you ever reported a problem and wondered how to “sign off” to get a new feature or bug fix in to Koha? Does the thought of signing off on a bug seem scary? Well our friends at BibLibre have created some sandbox systems (systems that have Koha installed already for you) so that anyone can test and sign off on patches no matter what your skill level is. Don’t worry there will no need to talk code in this post, nor will you need to know anything about Linux, Perl, etc. I’m going to show you how, even from your Windows machine, you can test and sign off on patches for the Koha community. So let’s get started.

The first thing you will need to do is to sign up for a Bugzilla account if you don’t already have one. Sign up is easy and fast, simply go to http://bugs.koha-community.org and click the button to “Open a new account.” Once you have an account, let’s go look for some bugs to test and signoff on!

The first thing I did (to make searching easier) was to edit my preferences. Click on “Preferences” located at the top or lower portion of Bugzilla (it’s next to the Log out). Then click on Saved Searches and place a checkmark next to “Needs Signoff” (it’s been shared by Chris Cormack), click “submit changes” and now when you get back to the Home page you’ll see a “Needs Signoff” in the footer portion of the page (it’s under My Bugs).

Now the fun begins.

Click your newly created “Needs Signoff” option and then sort on the “Comp” heading. This will sort all the bugs via the module or component. Now it’s just a matter of finding a patch you want to test. I started with simple ones, ones that were just wording changes so that I could get the experience under my belt. One thing to note is most but not all, patches will have a test plan. If there is one great, if not we encourage you to post a comment to that developer asking for a test plan. Also note which version the patch is for.

Now that you found a bug to test, head over to BibLibre’s sandboxes http://wiki.koha-community.org/wiki/Sandboxes If you scroll all the way to the bottom you will see a listing of available sandboxes. Here are the steps to test a bug:

  1. Go to a sandbox and click on the URL to set up the sandbox. Please pay attention to the date of the current sandbox setup (it’s under the heading Welcome to the Koha sandbox tester). If the date is today, please don’t use that sandbox as that person who set it up might still be testing something. Simply go back to the listing and choose another one that has an older set up date.
  2. Enter the bug number, your name, email, and type Koha in the anti-spam box. For the database choose MARC21 unless you are testing a couple of patches.
  3. Check your email for a message that your sandbox is ready.
  4. Once it’s ready, go back to sandbox wiki page and go into the staff interface URL and log in with test/test You’ll see under News on the left that you are in a sandbox.
  5. Check the patch.
  6. If you are satisfied that the patch works as designed, go back to sandbox page (where you were for step 2) and towards the bottom you’ll see “Sign-off”, enter the bug #, your name, your email, and Koha for the anti-spam.
  7. Click OK.

You have now tested and signed-off on a patch! If you go back to that bug # in Bugzilla at the bottom you will see a comment that you have tested and signed off on the patch using the sandbox. Don’t worry if you don’t see it right away, keep refreshing the Bugzilla page, it will show up but might take a couple of minutes.

Easy-peasy lemon squeezy!

The post Playing in the Koha sandbox by appeared first on ByWater Solutions - Koha Open Source ILS Support.

How Koha 3.12 Handles Lost Statuses

$
0
0

One of the most common questions we get about Koha is how lost statuses are handled. Hopefully this handy guide will be of use in that area.

If the long overdue cron job is running with these settings:

misc/cronjobs/longoverdue.pl --lost 60=2 --charge 2 --confirm

The following actions are taken:

  • charges the patron the replacement price from the item
  • marks the item ‘long overdue’
  • keeps the item listed on the patron’s check out history
  • when checked in the item is marked ‘not lost’
  • when checked in the patron is refunded the lost fee (if the RefundLostItemFeeOnReturn preference says so)
  • when checked in the item is removed from patron record

If the long overdue cron job is running with these settings:

misc/cronjobs/longoverdue.pl --lost 60=2 --charge 2 --mark-returned --confirm

The following actions are taken:

  • charges the patron the replacement price from the item
  • marks the item ‘long overdue’
  • item removed from patron’s checkouts
  • when checked in the item is marked ‘not lost’
  • when checked in the patron is refunded the lost fee (if the RefundLostItemFeeOnReturn preference says so)

If you go to the detail page and click on the items tab on the left and then mark the item lost the following happens:

  • item marked ‘lost’
  • charges the patron the replacement price from the item
  • item removed from patron’s checkouts
  • patron refunded when item checked in (if the RefundLostItemFeeOnReturn preference says so)
  • item status changed when checked in

If you go to the detail page and click on the items tab on the left and then mark the item lost and paid for the following happens:

  • item marked ‘lost and paid for’
  • charges the patron the replacement price from the item
  • item removed from patron’s checkouts
  • patron refunded when item checked in (if the RefundLostItemFeeOnReturn preference says so)
  • item status changed when checked in

If you go to the detail page and click on the items tab on the left and then mark the item missing the following happens:

  • item marked ‘missing’
  • charges the patron the replacement price from the item
  • item removed from patron’s checkouts
  • patron refunded when item checked in (if the RefundLostItemFeeOnReturn preference says so)
  • item status changed when checked in

If you go to the detail page, click on the Edit > Edit items button, click Edit next to the item you want to edit and then mark the item with any lost status the following happens:

  • item marked with the lost status
  • the patron record remains untouched

The post How Koha 3.12 Handles Lost Statuses by appeared first on ByWater Solutions - Koha Open Source ILS Support.

Patron Usernames in Koha 3.12

$
0
0

“Koha is assigning a default username and password when I add a new patron.  What is the password?”

If you’ve had the same question, you are not alone!  I have been seeing a lot of tickets with a similar question cross my desk since the latest Koha upgrade to 3.12.  You have probably noticed that Koha is now assigning a default username to new patrons when you do not enter one.  It is defaulting to the format of firstname.lastname.  example: jane.smith

Koha is not, however, assigning a default password to patrons.  It appears to be assigning a password due to the asterisks (****) that appear next to the password on the patron screen and in the text box when editing a patron.  The asterisks are standard for a password field are not an indication of the existence of data in the field or the length of any data in the field.  In looking at the database the password field is actually blank.

The behavior of the username/password fields is the same if you are adding patrons one by one in the Patron module of Koha or if you are bulk importing patrons through the Tools module.   Both methods of patron entry will result in a username of firstname.lastname with blank password if none is specified by the user.

I hope this helps clarify any questions you may have about these two fields in Koha 3.12.  If not, let us know!

-joy

 

Update: 1/13/2014- Just remember that users cannot log in to Koha unless you assign them a password!  The blank password is not a valid password.

The post Patron Usernames in Koha 3.12 by Joy Nelson appeared first on ByWater Solutions - Koha Open Source ILS Support.

Spring is in the air: Refreshing your Koha OPAC via handy plugins

$
0
0

After the long winter for some of us in the north and the ice down south, we are all waiting for spring to arrive. The time to open our windows and clear out the dust but what about your OPAC? Is it looking dull? Has it not weathered the winter? Does it need a splash of color? With a few edits to OPACUserCSS system preference you can refresh your Koha OPAC and bring some life back to it.

Editing the OPACUserCSS is easy-peasy-lemon-squeezy, and you don’t need excessive CSS knowledge to do so. The easiest thing to do is install the Firebug plugin for Firefox, Chrome or Windows at https://getfirebug.com/downloads/. Once this is plugin is installed you can right click anywhere and choose “Inspect Element with Firebug”. By doing so a window will open on the bottom, and you can see what div that portion of the page is using and you also be able to see what CSS that portion is listed under. Firebug has a nifty aspect to it where you can edit the page live to see what it would look like before actually making the change to OPACUserCSS, just remember you’ll have to make your change there once you are happy with the color.

Another helpful plugin is ColorZilla. ColorZilla has an eyedropper aspect to the tool which you can click on any portion of the page and find out what the hex code for that color is. So if you have a favorite site which you love their color scheme you can see what hex code they are using and apply it to your Koha OPAC. Once you know what color your OPAC is currently using you can find where it’s referenced in OPACUserCSS and change it accordingly.

Not sure what color to use to freshen up your OPAC? Head over to this site http://www.w3schools.com/tags/ref_colorpicker.asp. Here you can choose the color and then shade for the perfect color and the site provides you with the hex code. Be warned it’s sort of like standing in front of the color samples at Home Depot trying to pick the perfect color for your living room.

Between these three tools, you’ll be able to freshen up your Koha OPAC just in time for spring. Happy spring cleaning!

The post Spring is in the air: Refreshing your Koha OPAC via handy plugins by Melissa Lefebvre appeared first on ByWater Solutions - Koha Open Source ILS Support.

Setting up Receipt Printers on Ubuntu for Koha

$
0
0

Today a tutorial from one of our newest partners, Sean Park at the Coos County Libraries. A message came across our mailing list asking the following:

We are new to Koha and ByWater, and everything is great so far. But we’ve have some trouble with our old receipt printers that we used under TLC. I think they are Bixolon printers, SPR 350′s, that connect through USB. I have played with some drivers that make them work a little bit, but don’t want to fight with them for months and months, or to have to search for some obscure driver to make them work. We are using Koha in the Ubuntu desktop on our staff machines, and I wondered if anyone else used Koha on linux machines, and what receipt printers worked best for them? I’d be happy to just replace our old receipt printers, as I only need 3 of them. I welcome any advice!

And Sean replied:

This morning I finished setting up new Star TSP100 (TSP143LAN) thermal receipt printers in anticipation of our migration in a few weeks. Coupled with the JSPrintSetup add-on in Firefox they are automatically printing receipts with no popup dialog, and setup was quite easy. We’re on Ubuntu 12.04. If you’d like instructions for installing Star drivers, just let me know.

So, of course I asked him to share those instructions with us all. Here are Sean’s instructions for setting up Star TSP100 (TSP143LAN) receipt printers on Ubuntu 12.04:

  1. At the command line type:
    sudo apt-get install libcups2-dev libcupsimage2-dev
    cd /tmp
    wget http://www.starmicronics.com/support/DriverFolder/drvr/starcupsdrv-3.4.0_linux_20121210.tar.gz
    tar -xzf starcupsdrv-3.4.0_linux_20121210.tar.gz
    cd starcupsdrv-3.4.0_linux/SourceCode
    tar -xzf starcupsdrv-src-3.4.0.tar.gz
    cd starcupsdrv/
    make
    sudo make install
    
  2. Install the JSPrintSetup add-on in Firefox and add your Koha staff URL to the list of allowed sites in JSPrintSetup preferences.
  3. In Koha preferences enter the following in the IntranetSlipPrinterJS field (tailor to your needs, this is what our TSP100′s use):
    function printThenClose() {
    try
    {
        jsPrintSetup.clearSilentPrint();
        jsPrintSetup.setOption('printSilent', 1);
        //Set Header and footer
        jsPrintSetup.setOption('headerStrLeft', '');
        jsPrintSetup.setOption('headerStrCenter', '');
        jsPrintSetup.setOption('headerStrRight', '');
        jsPrintSetup.setOption('footerStrLeft', '');
        jsPrintSetup.setOption('footerStrCenter', '');
        jsPrintSetup.setOption('footerStrRight', '');
        //Set margins
        jsPrintSetup.setOption('marginTop', 0);
        jsPrintSetup.setOption('marginBottom', 2);
        jsPrintSetup.setOption('marginLeft', 1);
        jsPrintSetup.setOption('marginRight', 1);
        jsPrintSetup.print();
        window.close();
     }
     catch(err)
     {
        //Default printing if jsPrintsetup is not available
        window.print();
        window.close();
     }
     }
    
  4. Edit your slips in Koha “notices & slips“. Eg. our quick slip looks like this:
    <img src="http://www.cooslibraries.org/screens/lilc.png" />
    <h3>Coastline Libraries - Coos County</h3><br />
    <checkedout>
    <<biblio.title>><br />
    <h3>Date due: <<issues.date_due>></h3><br />
    Checked out from: <<branches.branchname>> Library<br />
    Checked out to: <<borrowers.title>> <<borrowers.firstname>> <<borrowers.initials>> <<borrowers.surname>> <br />
    Checked out on: <<today>><br />
    </checkedout>
    <br />
    Thank you for using Coastline Libraries!
    <!-- end slip -->
    

The post Setting up Receipt Printers on Ubuntu for Koha by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

Printing Lists the “Old Way” in Koha 3.14

$
0
0

I’ve been teaching our partners all about Koha 3.14 and one of the great upgrades that comes with 3.14 is a new interface for lists in the staff client. I happen to love this new look and feel, but a few of our partners noted that the new printable version of the list is a bit long for their liking so in true Koha and open source fashion I was able to write them a report that would generate a list in the way they wanted to print it:

select concat(b.title, ' ', ExtractValue(bi.marcxml, '//datafield[@tag="245"]/subfield[@code="b"]')) as Title, 
       b.author, c.dateadded, GROUP_CONCAT(DISTINCT i.itemcallnumber SEPARATOR ' , ') AS 'Call Number(s)' 
from virtualshelves l 
left join virtualshelfcontents c using (shelfnumber) 
left join biblio b using (biblionumber) 
left join items i on (b.biblionumber=i.biblionumber) 
left join biblioitems bi on (b.biblionumber=bi.biblionumber) 
where l.shelfname like <<List name like (use % for wildcard)>> 
group by b.biblionumber
order by b.title asc

To print out the list just enter the list name exactly right when asked by Koha or enter it with % around it. So %research% will find any list with the word ‘Research’ in the list name.

The post Printing Lists the “Old Way” in Koha 3.14 by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

When anti-spam measures go too far?

$
0
0

There’s been a recent event that has many systems administrators up in arms. No, I don’t mean Heartbleed. I’m talking about Yahoo and how they have broken pretty much every mailing list in existence.

Some background:

There are a number of techniques out there for combating SPAM. They range from filters looking for keywords, to blacklisting servers, to Internet standards such as SPF and DKIM. Well now Yahoo has taken it a big step further with DMARC.

DMARC is a new anti-spoofing technical specification (no, it has nothing to do with libraries or MARC records, despite the coincidental acronym). DMARC stands for “Domain-based Message Authentication, Reporting & Conformance” (http://www.dmarc.org/). DMARC is not an international standard yet, but many mail vendors are already supporting it. Like most technical specifications, it’s complicated and pretty dry reading, but in a nutshell what DMARC says is this:

When an email is sent, it includes a number of headers, in addition to the visible fields like “To”, “From”, “Subject”, etc. Among these headers is the domain name of the server that sent the message. DMARC requires that the domain in the “From” field must be in the same domain as the sending server. So for example, if the originating server of an email message is “mail.my-server-domain.com”, but the “From” address is “random.user@yahoo.com”, that violates DMARC.

When a vendor implements DMARC they create a DMARC policy record for their domain that specifies what they want done if the “From” address is different than the mail server domain. This policy record includes a “p=” statement, where the value of “p” can be either “none” (do nothing, accept the email) or “reject” (reject the message).

Now surely anything vendors can do to cut down on spam is a good thing, right? But let’s think about that for a minute. When you subscribe to a mailing list, and then post a message to it, your message goes out with your address in the “From” field. But, the server hosting the mailing list is what is actually sending the message out to the subscribers, and so now the originating server will be that of the mailing list provider, not your original email vendor. The domain name in the “From” field will now be different than mail server domain, and according to DMARC, that’s a no-no. Using a mailing list is a completely legitimate thing to do, and for a mailing list to rewrite headers is also quite normal and a reasonable thing to do. The commonality of this practice is surely one of the reasons why most vendors who currently have a DMARC policy record have it set to “p=none”.

So what happened? Last weekend (sometime between April 4-6) Yahoo changed their policy from “p=none” (accept messages) to “p=reject”. Yahoo is now saying, “nope, we will not accept any message with a yahoo.com ‘From’ address did not originate from a yahoo.com server.”

And the problem isn’t just contained to Yahoo. Other mail vendors that perform DMARC checks see Yahoo’s policy and will ALSO reject email messages sent to their subscribers that purport to come from yahoo.com. So for example, if a message from a Yahoo user goes through a mailing list, Gmail will respond with a message that reads: “smtp;550 5.7.1 Unauthenticated email from yahoo.com is not accepted due to domain’s DMARC policy. Please contact administrator of yahoo.com domain if this was a legitimate mail.”

So Yahoo updated their policy to “reject”, and just like that, thousands and thousands of email messages all over the world suddenly started bouncing back. And mailing list administrators are inundated with rejection notices.

Okay, so you might say to yourself, “I don’t operate a mailing list, how does this affect me?” Let’s take an example closer to home. In Koha, you have the ability to set the KohaAdminEmailAddress system preference, which serves as the general “From” address for messages sent by Koha. In addition, you can define an email address for each branch library in your system. These email addresses can be anything, and may range from something in your local domain, to gmail accounts, hotmail accounts, and even yahoo accounts. But, the mail server that is sending this message may NOT be in your local domain. For example if you host with us, your server’s “official” name will be in the “bywatersolutions.com” domain, but your “From” addresses will not be a ByWater address. So technically pretty much every email sent by a Koha server that is hosted outside of your local domain will be in violation of DMARC.

I’ll pause for a moment to let that sink in.

Okay, let’s take a breath; things are not totally hopeless. Right now Yahoo appears to be the only mail vendor who’s using a DMARC policy of “reject”. That means that as long as you don’t use a yahoo.com address for your KohaAdminEmailAddress or branch email addresses, you should be okay. (And cross your fingers that Gmail doesn’t change their DMARC policy.) And in fact, this is the very advice being given by a number of mailing list administrators out there; don’t use Yahoo. But that is a short-term solution.

For the long-term, a development idea has been submitted to the Koha Community to address this. You can follow the Bug report here: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9530

What this development seeks to do is allow for a separate “Reply to” setting in Koha, in addition to the current “From” setting. This should address the problems of DMARC, since at this time DMARC is only concerned with the “From” address. How this would work is, you would still have to use a “From” address that matches the domain of your Koha server, and this is what will show up in the “From” field of messages sent to your borrowers. You might end up using something like “No_Reply@my_koha.domain.com”. But with this development you would also have a “Reply to” header in your email that can be a real address, outside of the hosting domain. So even though the email message would say that it’s from “No_Reply@my_koha.domain.com” bouncebacks would return to your local email account.

At the moment, this development has just been submitted, so I don’t know how much work as been done on it yet. But hopefully something can be done with this before the next big mail vendor decides to change their DMARC policy as well. If any of you out there want to help with this development, by all means, get involved: http://koha-community.org/get-involved/

Further reading:

 

The post When anti-spam measures go too far? by Larry Baerveldt appeared first on ByWater Solutions - Koha Open Source ILS Support.


Entering Good Support Tickets, Revisited

$
0
0

Two years ago, Thatcher Rea posted Entering Good Support Tickets. I felt that there was more to be said on the topic.

Technical support is one of the primary services that we provide at ByWater Solutions. Our goal is to provide answers to your technical issues as quickly as possible, and to provide the best quality service possible — solving the problem the first time, rather than having to revisit issues multiple times.

In order to do this, we need to get the best possible descriptions of technical problems up front.

Note: I’ve used the ByWater Solutions’ Demo Koha Staff Client for examples below. Username = bywater Password = bywater.

The Subject line of your email counts — make is short and sweet

The first thing that we see when a support ticket arrives is the subject line. A well written subject may be the difference between a ticket that gets solved in five minutes and one that takes hours or more to resolve. The subject should be memorable and should point us in the right direction.

Text is better than pictures

Screen shots have their place — some times they can tell a story that is difficult to put into words — however it is impossible to copy and paste text from a screenshot. Screenshots should be used for illustration and clarification, but the body of the description must contain text.

Always copy and paste — don’t retype.

There are certain pieces of information within a trouble ticket that are useless if they are not typed correctly: biblionumbers, barcodes, item numbers, URLs will all fail if mis-typed. Error messages on screen should also be copied if at all possible.

Including URLs: The secret weapon of Koha support.

Because Koha is a web based application, the URL will, at the very least, tell us which web address is causing the error. In fact, the URL can contain a good deal more information than that. For instance, the URL http://intranet.bywatersolutions.com/cgi-bin/koha/members/moremember.pl?borrowernumber=165 contains two parts: http://intranet.bywatersolutions.com/cgi-bin/koha/members/moremember.pl is the address of the page that handles patron information, and ?borrowernumber=165 specifies patron number ’165′ on that page. Copying and pasting the full URL of a page that is causing problems can supply a lot of information in a trouble ticket. This is especially helpful when a page is displaying an error message of some kind.

Information to include in a support ticket:

Where does the problem occur?

  • In the OPAC?
  • In the Staff Client?
    • What part?
      • Circulation?
      • Search?
      • Holds?
  • Paste the URL into the ticket.

Is there an error message?

Paste the text into the ticket.

Always include an example patron, item or title. Names are good, ID numbers are better:

Patron:
  • Good: First Name, Last Name
  • Better: Cardnumber
  • Best: Borrowernumber / Patron URL
Item:
  • Good: Title
  • Better: Barcode
  • Best: Itemnumber / Item URL
Title (I.e. biblio record)
  • Good: Title
  • Best: Biblionumber / Biblio URL

How often does this problem occur?

  • Are there issues every time you try?
  • If the problem is intermittent, How often Does it occur on average: Once per hour? Once per day?

Describe, step by step, how to replicate the problem.

  • Be as detailed as possible.

What Web browser are you using?

  • Brand: Microsoft Internet Explorer, Mozilla Firefox, Google Chrome
  • Version: Go to the help menu, choose ‘about’ and paste the version number into the ticket.

Is the issue browser specific (e.g. does the issue occur in Chrome but not Firefox, or vise versa)?

Are there logs available?

  • There are several system preferences which enable logging. Make sure that logging is enabled for whichever system you are having issues with.
  • When the problem re-occurs, Go to Tools > Log Viewer.
  • Put item number in the ‘Object’ text box
  • Narrow the date range.
  • Click ‘submit’ to search the logs.
  • Paste the results into the trouble ticket.

Have you cleared the browser cache?

Certain javascript heavy pages, such as circulation, can save information for re-use. Under certain circumstances, this information can get out of date, causing unpredictable behavior. Try clearing the browser cache.

Can you capture the problem in a screencast?

See http://bywatersolutions.com/2011/12/14/screencasts-for-koha-bugticket-reporting/

Examples:

Subject:

Bad:
  • It’s broken
  • Error Message
  • It won’t print
Better:
  • Error Message in catalog search for ‘Harry Potter’
  • Problem printing quick slip on checkout.
Best:
  • staff client mainpage.pl catalog search for ‘Harry Potter’ causes ’404 Page Not Found’
  • Circulation: title does not print on quick slip, checking out barcode E12073366

Description:

Bad:
  • When I was checking out an item, the slip messed up.
Better:
  • When I was checking out ‘Harry Potter’, the title did not print on the quick slip
    • This would be a reasonable subject line, but lacks detail.
Best:
  • Steps to re-create the problem:
    1. Start at Home > Circulation > Checkouts (http://intranet.bywatersolutions.com/cgi-bin/koha/circ/circulation.pl)
    2. Enter Card Number for patron ‘Pikov Andropov’, card number 443 in search bar with ‘Check Out’ enabled.
    3. Scan Barcode ‘E12107351′ (title: Practical open source software for libraries /)
    4. Check ‘Cancel hold’ check box then clicked ‘Yes, Check Out (Y)’
    5. Click ‘Print’ button, selected ‘Print Quick Slip’
    6. At this point, I expect to see all of the information about ‘Practical open source software for libraries’ printed on the slip — the barcode and due date do print, but the title does not.
  • I took a picture with my cell phone of the slip as it printed — I’m pointing to the place where the title should appear. The jpeg is attached to this email.

Future blog posts will detail information to include for specific types of problems.

The post Entering Good Support Tickets, Revisited by Barton Chittenden appeared first on ByWater Solutions - Koha Open Source ILS Support.

Guest Post: Getting MARC Records from Amazon

$
0
0

Today’s guest post was submitted by Jeremy Wellner at the Stanwood-Camano School District.


I’ve gotten a process figured out to actually make Amazon give us a MARC record for us to import into Koha. :)

  • Grab evil hard to catalog item….
  • Visit http://amazon.libcat.org/cgi-bin/azorder.pl and scan in the ISBN
  • Click Export and it will download a file called azmarc.lfts
  • Go into your Koha Staff Client and pick Tools.
  • Pick Stage MARC for Import
  • Then you are going to click Choose File and locate that azmarc.lfts file we downloaded earlier.
  • Click Upload File and then scroll down further and click Stage For Import
  • After the record is staged, click on Manage Staged Records and finally Import This Batch Into the Catalog.
  • You’ll see the record number field populated below and voila! You’ve grabbed a record out of Amazon and put it into Koha! (Like this one! ).
  • Then it’s just a matter of going to that bib record and adding an item to it. Click on the record number (or right click and open a new tab with it), click on the New button and pick New Item.

It should also be noted that the online tool can have several items in it’s export file that can be imported into one batch.

This should also work great for textbooks as well!

The post Guest Post: Getting MARC Records from Amazon by ByWater Partners appeared first on ByWater Solutions - Koha Open Source ILS Support.

Koha Lists Form Focus

$
0
0

I’ve had a few partners contacting me asking if there is a way to make the cursor focus on ‘add to’ box on the lists function in the Koha staff client. The answer is of course!

So, when looking at a list in the staff client, the box to add more items to the list is at the bottom:

Add to Koha List

If you’d like your cursor to focus down in that box by default you just have to add the following to your intranetuserjs system preference:

$(document).ready(function(){
if (window.location.href.indexOf("virtualshelves/shelves.pl") > -1) {
$("input[name='addbarcode']").focus();
}
});

See this and other custom JQuery on the Koha wiki.

The post Koha Lists Form Focus by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

Inventory in Koha

$
0
0

Today seems to be the day of Inventory related tickets and phone calls at ByWater so I thought I should share what we learned (and what we taught our partners) with you all.

First off, Koha has an inventory tool … did you know that? Have you tried it out? It’s great getting to show the tool to our new partners in training because it’s so easy to use. I’ve even urged libraries who have never done inventory (yes I said ‘never’) to do inventory once they switch to Koha because it’s such an easy task. If you want to see the inventory tool in action you can check out my tutorial video.

Now, for what we learned/taught today:

Inventory might timeout. There is a bug in the inventory tool that has been fixed and will be released soon that makes it timeout for large libraries. From the bug report:

When you upload a file of barcodes, and do not specify any filters on the rest of the form, it effectively runs GetItemsForInventory() such that *every* item in the database is returned. On a large enough database, this takes so long that the script times out.

The current documentation in the manual implies that if you upload a file of barcodes, the *only* thing it does is set the date-last-seen field. This is not entirely true; it also tries to compare the list of scanned items to what is expected to be seen in the list of items.

The work-around for libraries with a large number of item records is to, when uploading a file of barcodes, to also set the filters (e.g., library, shelving location, call number range, etc.) to specify the range of items that the file of barcodes corresponds to.

Inventory will check items in. Have you ever gone out to your favorite store and been disappointed to see that they closed early because they had to do inventory? There’s a reason for this. If you’re doing inventory while your customers/patrons are touching your inventory then your inventory report will be incorrect – or you’d never stop doing inventory. This is no different in the library. Inventory should be done in small batches or when the library is closed and your patrons aren’t touching things. When you do inventory in Koha you scan a shelf or two of barcodes and then load them in to Koha telling it to update the ‘date last seen’. Well the assumption (and rightfully so) is that the items you’re marking ‘seen’ have actually been ‘seen’ and touched by you on the shelf in your library. So when you load that file of barcodes in to Koha and set the date Koha not only updates the ‘date last seen’ it also checks the items in if they are checked out. As we all know things move quickly in our libraries and sometimes we think we scanned an item to check it in, but didn’t. We also have patrons who like to put books on the shelf themselves and bypass the circulation desk. These scenarios are all resolved when doing inventory.My recommendation (and what I tell all our partners in training) is to do inventory in small spurts. So, scan a shelf or two and then load the file in to the inventory tool in Koha. Rinse and Repeat until inventory is done. Or do inventory over a weekend when you’re closed or during the evening only (loading the file in every morning before the library reopens).

For those of you who think inventory should offer other options, there is an enhancement request out there with the community that you can look at that suggests a checkbox (or some mechanism) to not have Koha check in materials. There is also a bug report that says that Koha should remind/warn you that you’re about to check items in by doing inventory, but in my opinion this warning will come too late because you have already done all the work of the inventory.

Inventory is setting the date last seen to zero. This one I found today while testing the inventory tool. We are still waiting for more info on what’s causing it and how it can be fixed. For now, if you need to run inventory go right ahead. After running inventory either you or your support provider can update the database manually to put the right inventory date in. If you have access to your database you simple need to run:

update items set datelastseen='2014-05-28' where datelastseen='0000-00-00';

Where the date you enter is the date you entered when doing inventory.

If you don’t have access to your database then you can ask your support provider to run the above code for you.

Finding missing items after inventory. After you’ve run the inventory tool how do you find the items that are missing? Well you run a report to show you everything that hasn’t been seen since a specific date. I have written such a report and shared it on the Koha wiki.

What’s coming next? Since we’re talking inventory you might be interested in this big enhancement to the inventory tool that is looking for testers. It adds the following functionality to the inventory tool:

  • Have the tool warn of items possibly shelved out of order for scanned lists of barcodes ( by comparing to previous and next items ).
  • Ability to skip items with waiting holds ( in the same manners as items on issue are skipped ).
  • The ability to choose locations to not flag as “Item should have been scanned” if not scanned ( e.g. On Shelving Cart, On Display, etc )

The post Inventory in Koha by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

Sorting Reports by Date in Koha 3.14

$
0
0

It’s time for another post ripped right from the support system at ByWater. We’ve had a bunch of partners report to us that they can no longer sort their saved reports in Koha 3.14 by creation date. I have to admit I never even used this function so I didn’t notice that it had been removed. Why didn’t I use it? Because the ID column on the reports page is the first column and it’s an auto-increment column so that means that it’s actually the same as sorting by creation date. So, while we restore the sort function on the date column to your Koha saved reports, feel free to use the ID column to sort instead.
Sorting Koha Reports

The post Sorting Reports by Date in Koha 3.14 by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

Links to Koha Videos for Patrons

$
0
0

Today I had 2 partners ask me if we had updated the links to our Koha tutorial videos for partners since we had issues with our old video host last year. The answer is yes!! Here they are:

These are not updated for the new Bootstrap theme yet, but they are working videos for your patrons if you’d like to link to them.

The post Links to Koha Videos for Patrons by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

OPACBaseURL the most forgotten Koha system preference

$
0
0

As our partners know I have been pushing to get their Koha catalogs all upgrades to the new responsive theme as quickly as possible. One thing I did to find out what themes people were using was run a little query on all the sites we host:

SELECT value 
FROM systempreferences 
WHERE variable in ('opacthemes','OPACBaseURL')

The idea was to get me the name of the theme they were using and their public catalog URL. What I found was that many sites haven’t filled in their OPACBaseURL system preference and several of those who did fill it in filled it in wrong.

The OPACBaseURL preference is one I have all my trainees write down to fill in once they’re live (or once they know what their new public catalog URL will be), but it looks like a few of our partners skipped that bit of their homework. This preference might look like nothing important, but it’s actually used in a lot of places in your Koha public catalog and staff client. Per the manual:

This preference is looking for the URL of your public catalog (OPAC). Once it is filled in Koha will use it to generate permanent links in your RSS feeds, for your social network share buttons and in your staff client when generating links to bib records in the OPAC.

Important: Do not include a trailing slash in the URL this will break links created using this URL. (example: www.google.com not www.google.com/)

Important: This must be filled in with the URL of your public catalog for RSS, unAPI, and search plugins to work.

Important: This must be filled in with the URL of your public catalog to show ‘OPAC View’ links from bib records in the staff client

So this post serves as your reminder to go check out your OPACBaseURL system preference and make sure it’s populated and populated correctly!

The post OPACBaseURL the most forgotten Koha system preference by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.


Guest Post: Electronic library cards in Koha

$
0
0

Today we have a guest post by Paul Landers of the Texas Tech University Health Sciences Center, Preston Smith Library.


Inspired by the airlines’ electronic boarding passes, we are beta-testing some custom code on our Koha server to allow our patrons to self-service create a library eCard photo on their smartphone. See how it works here: http://www.ttuhsc.edu/libraries/ecards.aspx

Our solution relies upon a single new custom HTML file on our Koha server, a jQuery library to generate the barcodes, and some jQuery added to our OPAC. Also, Kyle had to add a patch to our Koha instance to expose the non-editable patron barcode field in the OPAC.

If any libraries would like to see it in action, here is a Hello World account for our OPAC:

eRaider username: hello_world
password: world


Our custom code:

  • NOTE – we had to replace some older barcode readers which could not read smartphone screens
  • Prerequisite – Koha must expose the non-editable patron barcode field in the OPAC.
  • Requires the jQuery barcode library (http://barcode-coder.com/en/barcode-jquery-plugin-201.html)
  • Must enable CORS (Cross Origin Resource Sharing) in Apache on the Koha server
  • Create the following custom HTML file on the Koha server:
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">
<script type="text/javascript" src="jquery_min.js"></script>
<script type="text/javascript" src="jquery_barcode.min.js"></script>
<script type="text/javascript">

//define our global
var cardnumber = "ERROR";

$(document).ready(function() {
//anonymous, self-executing function
    $(function () {
        if (window.opener != null && !window.opener.closed) {
// get some data from the parent window
            var parent = $(window.opener.document).contents();
            var cardnumber = parent.find("label:contains('Card number')").next('input').val();
            var surname = parent.find("#borrower_surname").val();
            var firstname = parent.find("#borrower_firstname").val();
            //var phone = parent.find("#borrower_phone").val();
            //var phonepro = parent.find("#borrower_phonepro").val();
            //var email = parent.find("#borrower_email").val();
            //var emailpro = parent.find("#borrower_emailpro").val();
        $("#surname").html(surname);
        $("#firstname").html(firstname);

$("#bcTarget").barcode(cardnumber, "code39", {barWidth:2, barHeight:100, moduleSize:3, showHRI:true});
         }
  });
});
</script>

<style>
img.center {
display:block;
margin-right:auto;
margin-left:auto;
}

#container {
max-width:500px;
border:solid;
border-width:2px;
}

#container2 {
width:350px;
margin: 0 auto;
}

p.center {
text-align:center;
}
</style>
</head>
<body>
<div id="container">
<img class="center" src="https://somelibrary.com/path/to/logo.png" />
<p class="center"><span id="surname">Lastname</span>, <span id="firstname">Firstname</span></p>
<div id="container2">
<div id="bcTarget"></div>
</div>
<p> </p>
</div>
</body>
</html>
  • Add the following jQuery to the OPAC:

 

//ecard barcode creator - requires a custom html file also be served by the Koha server itself.
// create the cardmaker function:
function cardmaker() { 
window.open('https://koha.somelibrary.edu/path/to/custom/html/file/','librarycard','height=300,width=500');
}

//add a new eCard button underneath the cardnumber field on the OPAC My Details page:
if (window.location.pathname.match(/.*opac-memberentry\.pl$/)) {
jQuery("label:contains('Card number')").parent().after('<li><button type="button" id="ecard">eCARD</button></li>');
jQuery('#ecard').click(cardmaker);
}

 

 

The post Guest Post: Electronic library cards in Koha by ByWater Partners appeared first on ByWater Solutions - Koha Open Source ILS Support.

Multiple Columns in Koha’s Bootstrap Theme

$
0
0

Many of our partners have a table on their main page listing new titles in their collection. Tables, however, are not responsive and so that cause issues on mobile devices when they upgrade to the Bootstrap theme. Today I learned about a built-in function of Bootstrap that makes it easy to emulate a table without actually creating a table. Bootstrap has 12 “columns” defined in it so you can easily create a multi-column display in your OpacMainUserBlock by using <div> tags with classes that add up to 12.

3 columns on an OPAC

For example this code will generate 3 columns like in the image above.

<div class="row-fluid">
<div class="span4"><p>Column 1</p></div>
<div class="span4"><p>Column 2</p></div>
<div class="span4"><p>Column 3</p></div>
</div>

When viewed on a mobile device though it will organize so that the “columns” become “rows” and display in a more friendly fashion.

3 columns on a mobile OPAC

Check out these other examples:

2 Column Layout

<div class="row-fluid">
<div class="span6"><p>Column 1</p></div>
<div class="span6"><p>Column 2</p></div>
</div>

4 Column Layout

<div class="row-fluid">
<div class="span3"><p>Column 1</p></div>
<div class="span3"><p>Column 2</p></div>
<div class="span3"><p>Column 3</p></div>
<div class="span3"><p>Column 4</p></div>
</div>

Thanks to Owen Leonard for teaching me this awesome trick!

The post Multiple Columns in Koha’s Bootstrap Theme by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

Adding Reports to the Koha Wiki

$
0
0

I recently received an email asking me if there were any tutorials on how to share reports on the Koha wiki. There were not … so of course I created one.

This tutorial will show you how to edit the Koha reports library on the official wiki so that you can share all of the great reports you’ve written for Koha. To learn more reporting tips check out this video.

The post Adding Reports to the Koha Wiki by Nicole C. Engard appeared first on ByWater Solutions - Koha Open Source ILS Support.

What I didn’t get to show at NAKUG ( covers that flow )

$
0
0

I’ve been working on a plugin for CCFLS that I was planning to show at the Koha North American Users Group (NAKUG) meeting but didn’t get a chance to, so here it is!

coverflow

Click to view animation

This is may take on a coverflow widget for Koha, implemented as a plugin! The title link at the bottom of each cover links to the record details for the given cover image.

coverflow_2

Click to view animation

How does it work you might ask? Well, first, let me give props to the author of Flipster, the most excellent responsive jQuery coverflow plugin I have found! This is the library that I used for the basis of my plugin.

Once the plugin is installed, the steps to get your coverflow to show up are as follows:

First, you need to create one or more public reports for your coverflow widget or widgets to be based on. This is how the plugin knows what the content of your widget should contain. Each report needs only three columns; title, biblionumber, and isbn. It is important that you have a good and valid isbn, as that is the datum used to actually fetch the cover. In the iteration of the plugin, we are using Amazon cover images, but I believe in the end I will make the cover image fetcher configurable so we can use any data source for cover image fetching.

Second, we need to configure the plugin. The plugin configuration is a single text area that uses YAML ( actually, it’s JSON, whcih is a subset of YAML ) to store the configuration options. In this example it looks like this:

- id: 42
  selector: #coverflow
  options:
  style: coverflow

In this example, we are telling the plugin to use the report with id 42, and use it to create a coverflow widget to replace the HTML element with the id “coverflow”. The options list is passed directly to Flipster, so any options supported by Flipster can be set from the plugin configuration! In fact, in addition to the traditional coverflow, Flipster has a “carousel” mode which is a much more compact version of the coverflow. You can also configure which cover the widget will start on, among other options.

At the time the plugins options are saved or updated, the plugin will then generate some minified JavaScript code that is automatically stored in the Koha system preference OpacUserJS. Here is an example of the output:

/* JS for Koha CoverFlow Plugin 
 This JS was added automatically by installing the CoverFlow plugin
 Please do not modify */$(document).ready(function(){$.getScript("/plugin/Koha/Plugin/Com/ByWaterSolutions/CoverFlow/jquery-flipster/src/js/jquery.flipster.min.js",function(data,textStatus,jqxhr){$("head").append("<link id='flipster-css' href='/plugin/Koha/Plugin/Com/ByWaterSolutions/CoverFlow/jquery-flipster/src/css/jquery.flipster.min.css' type='text/css' rel='stylesheet' />");$('#coverflow').load("/coverflow.pl?id=42",function(){var opt={'items':'.item','minfactor':15,'distribution':1.5,'scalethreshold':0,'staticbelowthreshold':false,'titleclass':'itemTitle','selectedclass':'selectedItem','scrollactive':true,'step':{'limit':4,'width':10,'scale':true}};$('#coverflow').flipster({style:'coverflow',});});});});
/* End of JS for Koha CoverFlow Plugin */

Why do this? For speed! Rather than regenerating this code each and every time the page loads, we can generate it once, and use it over and over again.

If you inspect the code closely, you’ll notice it references a script “coverflow.pl”. This is a script that is included with the coverflow plugin. Since we need to access this from the OPAC ( and we don’t want to set off any XSS attack alarms ), we need to modify the web server configuration for the public catalog and add the followup to it:

ScriptAlias /coverflow.pl "/var/lib/koha/mykoha/plugins/Koha/Plugin/Com/ByWaterSolutions/CoverFlow/coverflow.pl"

This line gives us access to the coverflow.pl script from the OPAC. This script retrieves the report data and passes it back to the public catalog for creating the coverflow widget. Koha::Cache is supported in order to make the widget load as quickly as possible!

The final step is to put your selector element somewhere in your public catalog. In this example, I put the following in the system preference OpacMainUserBlock:

<span id="coverflow">Loading...</span>

Once that is in place, you need only refresh your OPAC page, and there you have it, your very own catalog coverflow widget! Not only do these coverflows look great on a computer screen, but they look great on mobile platforms as well, and are even touch responsive!

Keep an eye out on the ByWater Koha Plugins page, you should see it there soon!

The post What I didn’t get to show at NAKUG ( covers that flow ) by Kyle Hall appeared first on ByWater Solutions - Koha Open Source ILS Support.

Using Koha and Linux to Power Bookmobiles

$
0
0

In today’s guest post, Alan Stolfus from the Rolling Hills Consolidated Library has a story to share with us about how their library is using open source software on their bookmobiles.


When the Rolling Hills Library bookmobile returns from a day of serving patrons in Andrew and Buchanan counties in northwest Missouri, team leader Deb Ezzell can lock its doors and call it a day.

Koha bookmobileAll because of the AT&T Mobile Hotspot MiFi, a cellphone-sized wireless access point.

Before getting the MiFi, Ezzell was recording patron transactions offline on a laptop notebook and uploading them into Koha ILS when she returned to the St. Joseph, Mo., library. With MiFi, Ezzell connects to Koha through the Internet and conducts transactions in real time.

“It saves us so much time,” she said. “It gives us the latitude as if we were operating right here in the library.”

Ezzell can check in and check out books and place holds for patrons while they’re on the bus. She also can see if they have overdue books or if their cards have been suspended, important information she wouldn’t have known before.

The library runs Linux Mint on the notebook. Linux has proven to be more reliable than other operating systems for the library, and the Mint distribution is user friendly.

The MiFi connection works as long as the bookmobile has cellphone coverage, which it does for all but one of its regular stops. On that day, Ezzell has a small amount of transactions to upload before heading home.

The post Using Koha and Linux to Power Bookmobiles by ByWater Partners appeared first on ByWater Solutions - Koha Open Source ILS Support.

Viewing all 208 articles
Browse latest View live