Koha 2.2 Users Guide

Koha 2.2 Users Guide Using the Power of Free and Open Source Software for Library Management March 2006 Stephen Hedges Joshua Ferraro and other contributors as noted in the text 2005-2006 LibLime This document is related to Koha and is licensed to you under the GNU General Public License version 2 or later (http://www.gnu.org/licenses/gpl.html). Koha-related documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. You may create a derivative work and distribute it provided that you: License the derivative work with this same license, or the Linux Documentation Project License (http://www.tldp.org/COPYRIGHT.html). Include a copyright notice and at least a pointer to the license used. Give due credit to previous authors and major contributors. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility. All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements. 2.2.3 2005-07-11 sh Initial XML markup, Introduction and Chapter One. 2.2.3p1 2005-08-18 sh Add Tools section, new systempreferences. 2.2.3p2 2005-10-02 sh Add user comments on printers, itemcallnumber. 2.2.4 2005-11-27 sh Update for version 2.2.4, add some user comments and section on Acquisitions 2.2.4p1 2005-12-17 sh Add more user comments, section on Backups, and appendices 2.2.5 2006-01-16 sh Conform to version 2.2.5, new material on acquiring MARC records and on templating. 2.2.5p1 2006-03-26 sh Add Chapter 3, Circulation Tasks 2.2.5p2 2006-07-03 sh Transfer copyright, change author e-mail address Introduction What is Koha 2.2? Koha version 2.2 is a free/libre open source integrated library system (ILS) for automating a lending library. It has all of the basic features needed to run a library, handling: an online public access catalogue (OPAC) of the library's holdings; a database of library users; issuing books to borrowers and returning books to the collection; borrower requests for library items; orders from vendors; book budgets; transfers between library branches; management of subscriptions to periodical publications; and most other functions associated with operating a lending library. Koha.2.2 supports MARC 21 and UNIMARC bibliographic records. While there are still a few ILS products that use their own format for storing bibliographic data, most commercial products have adopted some version of the venerable MARC (MAchine Readable Cataloging) record standard. MARC is an early markup language for handling the data and metadata that describe library materials. While there are some who argue that MARC is now outdated -- four decades after it was first developed -- it is by far the most widely used standard for the organization of bibliographic information, and Koha complies with this standard. Why use Koha instead of a commercial product? The main attraction of Koha is that it is free, since it is open source software. It is best to think of it as "free to change," however, rather than "free of cost." It is possible to set up a functioning Koha system without spending any money, but you will still spend more time on the implementation than you would with a commercial ILS (where you are paying the software vendor to set it up for you), and you will need to have a pretty fair knowledge of web server software (usually Apache) and the Perl programming language in order to configure some parts of Koha. Some knowledge of MySQL is also handy for database maintenance chores. Most libraries should probably plan on investing time, training, and some money before they have Koha up and running. That being said, Koha is still much less expensive than commercial library software, especially when you consider that there are no annual license fees. The best reason to use Koha is the fact that you will have complete control over your library software and data. Because the entire source code is open, a library can modify Koha to do things as the library wants them done. Commercial systems must aim their research and development for the "middle of the market," where most of their business can be found. But a library that wants to surpass the capabilities of most other libraries will find that Koha provides the freedom to try boldly imaginative innovations in library service. This book is a guide for Koha users -- in other words, for librarians. It is not intended to satisfy the needs of the computer technicians who are tasked with installing Koha, nor is it intended to offer guidance for extracting data from any ILS currently used by a library and loading it into Koha. Those needs are generally addressed by one or more of the documents available on the Kohadocs website (http://www.kohadocs.org). This book assumes that the basic installation of the Koha software has been completed, and procedures have been developed for migrating any existing data, and the computer technicians have handed the system over to the librarians. This book tells librarians what to do to configure Koha for use in their library, explains how to use Koha for day-to-day library operations, and provides a glimpse of some of the customization that can be done to make each library's Koha unique. Setting Up Your Koha System Once the Koha software has been downloaded and installed, it is not ready to use. While a commercial ILS will generally be delivered to you ready to use, you will have spent many hours with the vendor describing your library, your data, your cataloging practices, etc., so that the vendor can configure the software and make it useful to you. (At least that is what should happen if all goes well.) In the case of Koha, there is often no vendor involved, so you should be prepared to configure Koha yourself. This can be a very long and involved process (so this chapter is by far the longest chapter in this book), but it is not technically difficult -- unless you want to do some sophisticated customizing! When Koha is first delivered to the librarian(s), the technicians that have installed it will have set it up with two web addresses: one for accessing the Online Public Access catalogue (OPAC), and one for accessing what is generally called the "Intranet." The Intranet address is the one that will be used by the librarians to get to the Koha programs they will use to manage library circulation, cataloging, etc. Often the OPAC and the Intranet addresses are almost the same, the only difference being an additional ":8080" at the end of the Intranet address. So, for example, the OPAC address might be something like "http://www.mykoha.org," while the Intranet address will be "http://www.mykoha.org:8080." Whatever the addresses may be, the first thing the librarian will do is open a web browser and type in the given web address for the Intranet. If everything is installed correctly, the librarian should see a screen inviting him/her to login to Koha. The Intranet interface is tested only with Mozilla/Firefox. It should work (partially) with Internet Explorer. The OPAC should work fine with any navigator.

Koha Intranet Login Screen As with the web addresses for connecting to Koha, the librarian should have received the Koha administrator login name and password from whomever installed the software. If no other login name was chosen, "kohaadmin" is installed by default (but there is no default password, so you must get that from the person who performed the installation). Once you have completed the login, you come to the main page of the Koha Intranet.

Koha Intranet Main Page Although it is tempting to scroll down through the list of functions and start playing with Koha, please don't -- we have work to do! Before Koha is ready to use, you need to choose "Parameters" from the list of functions and tell Koha some important things about your library. The Parameters page is one of the busiest pages in all of Koha, with a long list of system parameters that must be set before you can use Koha (followed by a list of tools). Some of them have been set in the process of installing the software, but can be changed now if necessary.

Top of the Koha Parameters Page Don't let this list overwhelm you -- we will deal with each item individually and in some detail. The process of setting parameters will take some time, however, varying from a few hours to a few days, depending on how much time you will need to think about and organize your system data. Time spent in making wise decisions at this point will be amply rewarded in time saved later. Despite the fact that the screen says, "Fill these tables in the order they appear," we are going to skip to the bottom of the list of parameters and start with "System preferences."

System Preferences This page allows you to set the system preferences that control much of the basic behavior of Koha. These preferences should be set before any other parameters. If the system preferences page (or any other page you have seen so far) is in French, that means the installer(s) have installed both the English and the French "SQL Directories" (or only the French SQL Directory). While you can change the language of much of Koha from this page, the language of the descriptions that appear on this page cannot be changed. If your descriptions are in the wrong language, ask the installers to re-install now (before you start setting parameters) and install only your preferred language SQL Directory.

System Preferences page The layout of this page is pretty simple. Three columns list the name of the preference, its current value, and a brief description of what the preference controls. The preferences grouped into tabs relating them to Koha functions: Administration, Acquisitions, the catalogue, Circulation, Members, the OPAC, and some other preferences that do not fit into the other categories. Some of these you won't need to change at all. To change a preference, click on the folder icon. Don't click on the trash icon, which deletes the preference, unless you're a Koha developer -- and even then make a backup of the systempreferences table first. There is also a button at the bottom of the page for adding more system preferences. Most libraries will have no reason to either add or delete system preferences; the only time such action would be needed would be if a library was making some major changes to the Koha code. But the Koha philosophy is to give you as many options as possible, so this screen makes it easy to add and delete preferences if necessary. The preferences (variables) and their values are stored in the systempreferences table in the Koha database. When you choose to edit a preference, there is a standardized screen that appears to allow you to make your modifications. This screen requires some explanation.

System Preference Editing Screen The upper box in this window contains a very brief description of the system preference you are editing, the preference ("Variable") name, and its current value. This is the box in which you will make your changes and save them by clicking on the "OK" button. But what is that strange lower box labeled "Koha Internal" that tells you that you probably have no reason to change anything there? That box defines the type of values that you will be allowed to enter in the "Value" area of the upper box. In the screenshot that we are using as our example, the variable is the "acquisitions" system preference and the type (as defined in the lower box) is a "choice" variable -- meaning that you will be able to select a value from a pull-down list. The values that will appear in the pull-down list are defined in the "Variable options" area of the lower box. Had the variable been of a type that allowed you to type anything you wanted in the "Value" area (such as an e-mail address or an ISBD formula), then the "Variable type" in the lower box would be "free." If you wanted a bigger area for typing (and you might for defining an ISBD formula), then you could change "free" to "Textarea" and define the size of the text area by putting the number of columns and rows in the "Variable options" area. But in most cases, you will have no need to change anything in the lower box and will simply change the "Value" in the upper box and save it by clicking "OK." Again, Koha gives you the ability to change things you will probably never need to change -- but in case you might, you can. There is no recommended order for setting the preferences, so we will look at them group by group.

Admin dateformat Choose "metric," "us," or "iso" date format: "us" = mm/dd/yyyy "metric" = dd/mm/yyyy "iso" = yyyy/mm/dd This controls how dates are displayed on the Koha screens, not how they are stored in the database (usually yyyy-mm-dd). insecure If you are planning to be the only user of your Koha installation and find the login annoying, you can set this preference to "yes" to turn security off. But in almost every other case, the best choice is "no." If you choose "yes," users do not have to login and all information is open to anyone. Obviously, if your Koha is going to be used for a regular lending library, you want to have security turned on -- just say "no."

Acquisitions acquisitions The choices are either "normal" or "simple." "Normal" sets the system to track orders and update budgeting and vendor information as you add materials to your collection. "Simple" tells Koha that you are going to add materials to the collection without tracking orders. So if you plan to use Koha to monitor your budget and your orders with vendors, leave this preference as "normal." If you already have a system for monitoring your budget and orders (or simply don't plan to do any monitoring), change this to "simple." gist The "gist" is the "GST" (Good and Sales Tax) rate. If your local tax laws require you to pay taxes on purchases from your suppliers, enter the tax rate here, expressed as a decimal number and not a percent. (In other words, if the tax rate is 6.5 percent, enter ".065".). Set to "0" if you are not required to pay tax. The "gist" preference does not apply to fees and fines you charge borrowers, so if you are required to charge tax on such fees, you will need to include the tax in the fee amounts you set in the "Item types" and "Issuing rules" parameters.

Authorities authoritysep The description reads, "The separator used in authority/thesaurus. Usually '--'." What does that mean? Basically, Koha is asking what symbol is used in your language to separate the levels of your subject headings. In English, for example, subject headings and their subdivisions are separated by "--" as in "Women--United States--Bibliography." If a different symbol is used for this purpose in your language, change the value of this variable to that symbol. A detailed explanation of how Koha handles authorities will follow in the discussion of setting up your MARC parameters.

Catalogue ISBD Koha 2.2 can display records in a format that roughly conforms to the International Standard Bibliographic Description standards. ISBD is a family of standards developed by the Section on Cataloguing of the International Federation of Library Associations and Institutions (IFLA) to standardize, as much as possible, the descriptive portion of bibliographic records produced in different countries. The standards specify the descriptive elements constituting the record, their order, and the punctuation between them. (See http://www.ifla.org/VII/s13/pubs/isbdg2004.pdf) In order to do this Koha requires that you fill this field with the proper set of instructions, or formula, for organizing your MARC tags into an ISBD-conformant display. The online help (click "Help" in the upper right corner of the System preferences screen) provides some instructions and an example of a French language display using UNIMARC tags. Libraries using MARC 21 instead of UNIMARC probably have records that already contain punctuation conforming to the Anglo-American Cataloging Rules, second edition (AACR2). A reasonably good "AACR2" display can be constructed for such libraries, too -- just put something like this in the value field for the ISBD variable:#050|<label>Call Number: </label>|{082a}{050a}{ / 050b}| #100|<label>Main Entry: </label>|{100a}{ 100b}{ 100c}{ 100d}{110a}{ 110b}{130a}| #245|<label> </label>|{245a}{ 245b}{ 245c}{ 245h}{ 246i}{ 246a}| #260||{ 250a}{ 250b}{-- 260a}{ 260b}{ 260c}| #300| <label> </label>|{300a}{ 300b}{ 300c}| #020| <label> ISBN</label>|{ 020a}{ 024a}| #440| <label> </label>|{440a}{ 440v}| #500||{\n500a}| #511||{511a, }| #520|<label> </label>|{\n520a}{ 520b}| #600| <label>Subjects: </label>|{ 600a.}| #650|<label> </label>|{\n650a }{-- 650x}{-- 650z}{-- 650y}| #651|<label> </label>|{\n651a }{-- 651x}{-- 651z}{-- 651y}| #852| <label>Held at: </label>|{\n852a}{, 852b}{, 852c}| See the related comments in the User Comments section. autoBarcode The barcode number to be assigned to items is automatically assigned (sequentially) by Koha if this is set to "yes" ("1" = "yes") and you set your MARC preference to "no.". You will not be asked for a starting number or for any preferred type of barcode if you choose "yes" -- you simply get whatever Koha gives you. For most libraries, where preprinted barcodes are attached to items as they are cataloged, this will not work. In these cases, you should choose "no" and plan on adding the barcode to the catalogue record while you are adding other item information (such as price, accession date, etc.). hide_marc This is a feature for libraries that want to use MARC records, but don't want to see "too much" MARC. For librarians unfamiliar with MARC, some of the complexities of tags and subfields can be daunting. This feature hides some of those complexities. itemcallnumber This is one system preference that you may want to set after you set your other MARC parameters. This preference holds the MARC tag/subfield that is used to calculate the itemcallnumber variable that is a new Koha feature starting with version 2.2.2. If you set this preference now, please make a note of it and keep it handy when you set your other MARC parameters. If you decide to set it after setting your other MARC parameters, don't forget to come back to it! Prior to version 2.2.2, Koha could use several MARC subfields to hold various parts of a single call number that was assigned to a group of items related to a single bibliographic record. Displaying the call number correctly often required the user to modify some of the display templates to suit their individual library's cataloging practice. The itemcallnumber feature greatly simplifies Koha's handling of call numbers in screen displays, but the previous option is still available to Koha users. Putting an itemcallnumber subfield in a MARC record holdings tag allows you to set a call number on individual items, rather than on an entire group of items related to the same bibliographic record. While MARC holdings tags (either the 852 MARC 21 tag, or a user-defined 9xx tag) often contain subfields for holding particular parts of a call number, they may not have a subfield that is set up to hold the entire call number. If you choose to use item call numbers -- for example, to place a copy of a book in one branch in the reference collection, while in another branch it is placed in the non-fiction collection -- then you must use this preference to tell Koha which subfield in your MARC holdings tag contains the entire call number. Please note that in the example given above, the issuing rules for the item in the reference collection and for the item in the non-fiction collection will be the same: issuing rules are determined by the item type, not the item call number. To assign different issuing rules to the two items, they would have to be assigned to separate bibliographic records, with differing item types for each record. There will be more discussion of item types when we come to that section of our discussion of parameters. If you are migrating MARC records that do not have the entire call number in a subfield of the holdings tag, and you want to use the itemcallnumber feature, a programmer can write a simple script to compile the parts of your call numbers and insert the newly-constructed entire call numbers into your holdings tags. See the related comment in the User Comments section. marc This preference allows you to turn MARC support on or off. Set it to "no" if you do not intend to use MARC records. marcflavour Koha not only lets you specify whether or not you will be using MARC records, it also gives you a choice of MARC "flavors" -- MARC 21 or UNIMARC. Your choice will tell Koha how to interpret your MARC records.

Circulation ReturnBeforeExpiry This preference, if set to 1, will not allow a borrower to borrow items past the expiration date of their membership. Instead, Koha will recalculate the due date to be the same as the membership expiration date. This feature is useful for schools, which may set students' expiration dates to be the same as their graduation dates. The library would want all items to be returned before the students graduate and depart. maxoutstanding This preference sets the maximum amount of outstanding charges a borrower may owe before he/she is barred from making reserve requests. The number represents units of your local currency -- for example, "5" means "$5.00," if the dollar is your local currency. Partial "units" will be rounded to the nearest whole unit. For example, 5.25 will not be stored as "5.25," but as "5" -- so keep it simple! If you want to have no limits, leave this preference set at 0. maxreserves This preference sets the maximum number of active reserves a borrower can have at any one time. noissuescharge This sets the maximum amount of outstanding charges a borrower may owe before he/she is barred from checking out items. As with maxoutstanding, the number represents units of your local currency. printcirculationslips If your library uses receipt printers to provide borrowers with a list of items they have just checked out, you should turn this option on. If set to 1, circulation "slips" are printed on a receipt printer connected (or networked) to your server. If set to 0, no slips are printed.

Members NotifyBorrowerDeparture This system preference represents a number of days. If a borrower tries to check out items, and their registration is due to expire within this number of days, then the librarian sees a warning message. For example, is a borrower's registration is due to expire on the 15th of the month and NotifyBorrowerDeparture is set to 10, then beginning on the 5th of the month the librarian will see a warning if the borrower checks out items. This is a useful feature for schools, where a student's registration often expires on the date when they are scheduled to leave the school. Compare this system preference to the ReturnBeforeExpiry preference described in the preceding section. autoMemberNum The membership number (patron card number) to be assigned to new library users is automatically assigned by Koha if this is set to "yes" ("1" = "yes"). As with the autoBarcode preference, if you choose "1" you will not be asked for a starting barcode or barcode type. For libraries that use preprinted barcodes on their library cards, this preference should be set to "0" (="no"). Both autoBarcode and autoMemberNum refer to the visible numbers that will be attached to items and borrower cards. Koha will also assign internal control numbers for items and borrowers, called itemnumber and borrowernumber, that are both used for cross-referencing data in various Koha tables. These internal control numbers are always automatically assigned by Koha. checkdigit This preference determines the type of validity checks that will be done on membership numbers (patron card numbers): none or "Katipo" style checks. In almost all cases, you will choose "none." The checkdigit function was developed for the Horowhenua Library Trust ("HLT"), the library system that commissioned Katipo Communications, Ltd. to write the first version of Koha at the end of 1999. The function checks if patron card numbers that are automatically generated (when the autoMemberNum preference is turned on) are in the correct sequence and match pre-printed barcodes purchased by HLT. Unless you are starting a new library and using the same pre-printed barcodes used by HLT, you will leave this preference set to "none."

OPAC BiblioDefaultView This preference defines how Koha will display a bibliographic record that has been retrieved from a catalogue search. The choices are "normal," "marc" or "isbd." "normal" displays the record in the standard Koha format, showing most of the basic bibliographic information. "marc" displays the entire MARC record from Koha's MARC database. "isbd" displays an ISBD formatted record. (See the "ISBD" system preference below for more information about ISBD. All of these display modes can be modified by changing the HTML templates you are using, and you also have the ability to switch between views once the record has been displayed on the screen. This preference simply sets Koha's initial behavior when displaying a record. When first setting up your Koha system, "normal" is generally the best choice. LibraryName The text of this variable will be the library name and/or message that will be shown on the main OPAC page. If you are not familiar with HTML (Hyper-Text Markup Language), you may want to find someone to help with this. You will be using simple HTML tags to format your name and message. Here, for example, is the default name and message:Koha Free Software ILS Koha : a gift, a contribution in Maori The letters and slashes enclosed by wedges (<>) are the HTML tags. All text between and will appear in italics, all text between and will be in bold face, and the ("break") tags mark the ends of lines of text. OpacPasswordChange This preference controls whether or not a borrower can change their password through the OPAC. It is particularly useful for applications that use LDAP authentication for borrowers, since Koha would have no control over the LDAP password. SubscriptionHistory This system preference sets the type of details that OPAC users will see when they search for information about your library's periodical subscriptions. The choices are "simplified" or "full." simplified The OPAC user will see the name of the periodical, the date when the library began receiving the periodical, how often the periodical is issued, and the date when the library last renewed the subscription (or the date of the last issue received, if the library no longer subscribes). This information will be followed by a list of received issues and missing issues. full The OPAC user will see the name of the periodical followed by a list of issues, showing the date of each issue, the number of each issue, and the status of each issue -- arrived, awaited, late, or missing. hidelostitems If you do not want items in your catalogue which have been tagged as "lost" to appear in the results of OPAC searches, set this preference to "Yes." If you always want all items displayed, regardless of their "lost" status, leave this value set to "No." opaclanguages This preference sets your language preference. Despite the name, this choice can control the language used for all Koha screens, not just the OPAC. All of Koha is available in either English ("en") or French ("fr"), portions have been translated into Italian ("it") and Taiwan-Chinese ("zh-TW"), and more languages are being added. The top language in your list will be tried first when Koha displays a screen of information. opaclargeimage This system preference allows you to place your own custom logo on the OPAC main page. Normally, OPAC users will see the default Koha logo:

Koha logo If you want to use your own logo, this system preference should contain the path to your .gif image file. (The size of the default logo is 310x440 pixels.) opacsmallimage As with the opaclargeimage, this preference allows you to substitute a custom logo for the default Koha logo that normally appears in the upper left corner of OPAC pages other than the main page. (The size of the default small Koha logo is 35x50 pixels.) opacstylesheet In order to be compliant with the web standards recommended by the World Wide Web Consortium, Koha makes use of cascading style sheet (CSS) files to determine many of the aspects of how a Koha screen appears. The default CSS file for the OPAC is opac.css, which can be found in the /usr/local/koha/opac/htdocs/opac-tmpl/default/en/includes directory in most Koha installations. There is also a second choice of style sheet if you set this system preference to /opac-tmpl/css/opac2.css. If you would like to use your own cascading style sheet for the OPAC, enter the complete "href" path to the file as the value of this preference. For example, the href path (or URL) to the default style sheet would be /opac-tmpl/default/en/includes/opac.css. opacthemes Koha makes use of HTML templates to build the web pages that are displayed on the screen. By modifying these templates, the user can change the way data appears on Koha's screens. There are several groups of templates that have been developed which are complete enough to qualify as OPAC "themes," providing a consistent and distinctive look and feel across many of the Koha OPAC pages. Two themes in particular -- "css" and "npl" -- provide some interesting designs for OPAC pages: css is the current OPAC theme that is installed by default. (The theme that is actually named "default" is similar, but not currently as web compliant as the css theme.) Developed primarily by Paul Poulain, it uses cascading style sheets -- hence the name "css." Unless otherwise noted, the screen shots in this manual depict the css theme. npl is a completely different theme, though it also uses cascading style sheets. This theme was developed by Owen Leonard at the Nelsonville Public Library -- hence the name "npl."

OPAC home page in "npl" theme As with opaclanguages, the first choice on your list will be tried for each page, but if there is no template for that page in your chosen theme, Koha will revert to the default theme. In most Koha installations, the templates for each theme are found under the /usr/local/koha/opac/htdocs/opac-tmpl directory. suggestion If set to 1, the Suggestions feature is activated in the OPAC. This feature allows OPAC users to suggest book purchases. When a suggestion is made in the OPAC, it is assigned the status "ASKED." A librarian then manages the suggestion and can set the status to "REJECTED" or "ORDERED." When a book is ordered and has arrived in the library, the status becomes "AVAILABLE." Suggestions that are not yet "AVAILABLE" are visible to all users of the OPAC.

Koha OPAC home page with "suggestion" parameter activated. If the "suggestion" parameter is not activated or the user is not logged in, the "View and manage suggestions" button will not appear. virtualshelves This preference turns the virtual shelves option on or off ("1" or "0"). Users who login to the OPAC can set up and manage their own "virtual bookshelves" of favorite library items if this feature is turned on. There are three types of virtual shelves: Private These shelves can only be viewed or modified by the logged-in user who created them. For example, a borrower might select titles of books in the library's catalogue that he/she wants to read someday and can add these titles to a private virtual shelf for later reference. Public Any logged-in OPAC user can view these virtual shelves, but only the shelf creator can modify the contents. This type of virtual shelf might be used by a teacher to keep a list of library items for students to read, or a library might create "bestseller" lists for the public using public virtual shelves. Free Any logged-in OPAC user can view or modify these virtual shelves. These shelves thus become a sort of "public forum." Someone might start a free virtual shelf of "best computer books," for example, and other users could then add (or delete!) items from the list.

Others delimiter When exporting statistical data for reports, Koha can produce delimited files for importing into other applications. This preference sets the default delimiter. For instance, if you want Koha to produce comma-separated value (csv) files for importing into a spreadsheet application, you would choose the "," as the default delimiter. Disable_Dictionary The Koha OPAC by default allows users to "pre-search" the catalogue for words in titles, authors names, or subjects. This feature can greatly reduce the number of inappropriate records returned by a catalogue search, but some libraries may want to disable the feature by turning this preference on. The feature is accessed through the Advanced Search and is triggered by clicking on the three dots [...] after the Title, Author, or Subject search fields.

Dictionary Search By choosing from the list of terms returned by the dictionary search, a more accurate search of the general catalogue can be accomplished. IndependantBranches If this preference is turned on, all branches are treated as independent libraries working with one common database. Any staff member (with the necessary authority) can create basic bibliographic records for the database, or issue and return any book in the database. But staff at one branch cannot add items to another branch, or add borrowers to another branch, nor can they modify items or borrowers that "belong" to another branch. The exception to this rule is that any librarians with "superlibrarian" privileges can do any of these things; they are not restricted by this system preference. This preference does not affect the display of catalogue records in the OPAC -- searches will always display results from all branches. KohaAdminEmailAddress This is the e-mail address that will receive requests from borrowers for modification of their records. When borrowers login to the OPAC and review their accounts, they may see errors in their personal details. Koha allows them to fill out a form requesting corrections to their details, and this form is then e-mailed to a library administrator for review and action. This system preference tells Koha how to address those e-mails MIME Koha can export statistical reports to spreadsheet files in either Microsoft Excel or OpenOffice format. Use this preference to determine which format Koha will use. template This preference should probably really be called "intranetthemes," because it is the counterpart of the "opacthemes" preference. This preference controls which group of templates will be used for your Intranet screens. Currently the only choices are "default" and "npl." The "css" and "vanilla" themes that are available for the OPAC are not available here, because they do not provide Intranet templates. timeout This is the Inactivity timeout period (in seconds). If a workstation is idle for longer than this period, the user will have to login again. Now that you have set all of your system preferences, it's time to return to the Parameters page and work your way through the rest of the things listed there.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Joshua Allen Holm There is a minor problem with the ISBD values. The 082 entry for call number will not display when called on the #050 line. This block should fix the problem:#082|<label>Call Number: </label>|{082a}| #050|<label>Call Number: </label<|{050a}{ / 050b}| #100|<label>Main Entry: </label>|{100a}{ 100b}{ 100c}{100d}{110a}{ 110b}{130a}| #245|<label> </label>|{245a}{ 245b}{ 245c}{ 245h}{ 246i}{ 246a}| #260||{ 250a}{ 250b}{-- 260a}{ 260b}{ 260c}| #300| <label> </label>|{300a}{ 300b}{300c}| #020| <label> ISBN</label>|{ 020a}{ 024a}| #440| <label> </label>|{440a}{ 440v}| #500||{\n500a}| #511||{511a, }| #520|<label> </label>|{\n520a}{ 520b}| #600| <label>Subjects: </label>|{ 600a.}| #650|<label> </label>|{\n650a }{-- 650x}{-- 650z}{-- 650y}| #651|<label> </label>|{\n651a }{-- 651x}{-- 651z}{-- 651y}| #852| <label>Held at: </label>|{\n852a}{, 852b}{, 852c}| Anyone wishing to use these values, please note: When cutting and pasting the block above, it is very important to either remove all line breaks first or change the ISBD variable type to Textarea with the variable options 80|20 first. (Click OK after changing the variable type then click edit again to be able to paste the text into a text area). Posted by Thomas Dukleth I have seen that the postings on the koha and koha-devel lists have had very incomplete and inaccurate ISBD mappings from MARC 21 for use in the Koha ISBD System Preference. Here is a coded mapping for ISBD for MARC 21. The mapping that I have used follows the IFLA ISBD rules as closely as can reasonably be managed in the current Koha implementation with modest exception for some minor concessions to readability usage in Koha. Main author form is implemented appended before the first ISBD section which can be appropriate for a main author form. Subject headings have been separated by newlines for readability. It would be easy for the user to correct those issues. The initial main author may be removed. The newlines before 6XX $a may be replaced by a blank space. There are some punctuation and other issues remaining but they do not seem consistently resolvable without some major corrections to Koha functionality that would not happen before Koha 3.0. Some ISBD section closing punctuation might be improved with further experimentation. I have not thoroughly proofread my work but it seems to show no intrinsic problems to the extent that I have tested it. #100||{ 100a }{ 100b }{ 100c }{ 100d }{ 110a }{ 110b }{ 110c }{ 110d }{ 110e }{ 110f }{ 110g }{ 130a }{ 130d }{ 130f }{ 130g }{ 130h }{ 130k }{ 130l }{ 130m }{ 130n }{ 130o }{ 130p }{ 130r }{ 130s }{ 130t }| #245||{ 245a }{ 245b }{245f }{ 245g }{ 245k }{ 245n }{ 245p }{ 245s }{ 245h }| #246||{ : 246i }{ 246a }{ 246b }{ 246f }{ 246g }{ 246n }{ 246p }{ 246h }| #242||{ = 242a }{ 242b }{ 242n }{ 242p }{ 242h }| #245||{ 245c }| #242||{ = 242c }| #250| - |{ 250a }{ 250b }| #254|, |{ 254a }| #255|, |{ 255a }{ 255b }{ 255c }{ 255d }{ 255e }{ 255f }{ 255g }| #256|, |{ 256a }| #257|, |{ 257a }| #258|, |{ 258a }{ 258b }| #260| - |{ 260a }{ 260b }{ 260c }| #300| - |{ 300a }{ 300b }{ 300c }{ 300d }{ 300e }{ 300f }{ 300g }| #306| - |{ 306a }| #307| - |{ 307a }{ 307b }| #310| - |{ 310a }{ 310b }| #321| - |{ 321a }{ 321b }| #340| - |{ 3403 }{ 340a }{ 340b }{ 340c }{ 340d }{ 340e }{ 340f }{ 340h }{ 340i }| #342| - |{ 342a }{ 342b }{ 342c }{ 342d }{ 342e }{ 342f }{ 342g }{ 342h }{ 342i }{ 342j }{ 342k }{ 342l }{ 342m }{ 342n }{ 342o }{ 342p }{ 342q }{ 342r }{ 342s }{ 342t }{ 342u }{ 342v }{ 342w }| #343| - |{ 343a }{ 343b }{ 343c }{ 343d }{ 343e }{ 343f }{ 343g }{ 343h }{ 343i }| #351| - |{ 3513 }{ 351a }{ 351b }{ 351c }| #352| - |{ 352a }{ 352b }{ 352c }{ 352d }{ 352e }{ 352f }{ 352g }{ 352i }{ 352q }| #362| - |{ 362a }{ 351z }| #440| - |{ 440a }{ 440n }{ 440p }{ 440v }{ 440x }|. #490| - |{ 490a }{ 490v }{ 490x }|. #800| - |{ 800a }{ 800b }{ 800c }{ 800d }{ 800e }{ 800f }{ 800g }{ 800h }{ 800j }{ 800k }{ 800l }{ 800m }{ 800n }{ 800o }{ 800p }{ 800q }{ 800r }{ 800s }{ 800t }{ 800u }{ 800v }|. #810| - |{ 810a }{ 810b }{ 810c }{ 810d }{ 810e }{ 810f }{ 810g }{ 810h }{ 810k }{ 810l }{ 810m }{ 810n }{ 810o }{ 810p }{ 810r }{ 810s }{ 810t }{ 810u }{ 810v }|. #811| - |{ 811a }{ 811c }{ 811d }{ 811e }{ 811f }{ 811g }{ 811h }{ 811k }{ 811l }{ 811n }{ 811p }{ 811q }{ 811s }{ 811t }{ 811u }{ 811v }|. #830| - |{ 830a }{ 830d }{ 830f }{ 830g }{ 830h }{ 830k }{ 830l }{ 830m }{ 830n }{ 830o }{ 830p }{ 830r }{ 830s }{ 830t }{ 830v }|. #500| |{ 5003 }{ 500a }| #501| |{ 501a }| #502| |{ 502a }| #504| |{ 504a }| #505| |{ 505a }{ 505t }{ 505r }{ 505g }{ 505u }| #506| |{ 5063 }{ 506a }{ 506b }{ 506c }{ 506d }{ 506u }| #507| |{ 507a }{ 507b }| #508| |{ 508a }{ 508a }| #510| |{ 5103 }{ 510a }{ 510x }{ 510c }{ 510b }| #511| |{ 511a }| #513| |{ 513a }{513b }| #514| |{ 514z }{ 514a }{ 514b }{ 514c }{ 514d }{ 514e }{ 514f }{ 514g }{ 514h }{ 514i }{ 514j }{ 514k }{ 514m }{ 514u }| #515| |{ 515a }| #516| |{ 516a }| #518| |{ 5183 }{ 518a }| #520| |{ 5203 }{ 520a }{ 520b }{ 520u }| #521| |{ 5213 }{ 521a }{ 521b }| #522| |{ 522a }| #524| |{ 524a }| #525| |{ 525a }| #526| |{\n510i }{\n510a }{ 510b }{ 510c }{ 510d }{\n510x }| #530| |{\n5063 }{\n506a }{ 506b }{ 506c }{ 506d }{\n506u }| #533| |{\n5333 }{\n533a }{\n533b }{\n533c }{\n533d }{\n533e }{\n533f }{\n533m }{\n533n }| #534| |{\n533p }{\n533a }{\n533b }{\n533c }{\n533d }{\n533e }{\n533f }{\n533m }{\n533n }{\n533t }{\n533x }{\n533z }| #535| |{\n5353 }{\n535a }{\n535b }{\n535c }{\n535d }| #538| |{\n5383 }{\n538a }{\n538i }{\n538u }| #540| |{\n5403 }{\n540a }{ 540b }{ 540c }{ 540d }{\n520u }| #544| |{\n5443 }{\n544a }{\n544b }{\n544c }{\n544d }{\n544e }{\n544n }| #545| |{\n545a }{ 545b }{\n545u }| #546| |{\n5463 }{\n546a }{ 546b }| #547| |{\n547a }| #550| |{ 550a }| #552| |{ 552z }{ 552a }{ 552b }{ 552c }{ 552d }{ 552e }{ 552f }{ 552g }{ 552h }{ 552i }{ 552j }{ 552k }{ 552l }{ 552m }{ 552n }{ 562o }{ 552p }{ 552u }| #555| |{ 5553 }{ 555a }{ 555b }{ 555c }{ 555d }{ 555u }| #556| |{ 556a }{ 506z }| #563| |{ 5633 }{ 563a }{ 563u }| #565| |{ 5653 }{ 565a }{ 565b }{ 565c }{ 565d }{ 565e }| #567| |{ 567a }| #580| |{ 580a }| #581| |{ 5633 }{ 581a }{ 581z }| #584| |{ 5843 }{ 584a }{ 584b }| #585| |{ 5853 }{ 585a }| #586| |{ 5863 }{ 586a }| #020| <label>ISBN: </label>|{ 020a }{ 020c }| #022| <label>ISSN: </label>|{ 022a }| #222| = |{ 222a }{ 222b }| #210| = |{ 210a }{ 210b }| #024| <label>Standard No.: </label>|{ 024a }{ 024c }{ 024d }{ 0242 }| #027| <label>Standard Tech. Report. No.: </label>|{ 027a }| #028| <label>Publisher. No.: </label>|{ 028a }{ 028b }| #013| <label>Patent No.: </label>|{ 013a }{ 013b }{ 013c }{ 013d }{ 013e }{ 013f }| #030| <label>CODEN: </label>|{ 030a }| #037| <label>Source: </label>|{ 037a }{ 037b }{ 037c }{ 037f }{ 037g }{ 037n }| #010| <label>LCCN: </label>|{ 010a }| #015| <label>Nat. Bib. No.: </label>|{ 015a }{ 0152 }| #016| <label>Nat. Bib. Agency Control No.: </label>|{ 016a }{ 0162 }| #600| <label>Subjects--Personal Names: </label>|{\n6003 }{\n600a}{ 600b }{ 600c }{ 600d }{ 600e }{ 600f }{ 600g }{ 600h }{--600k}{ 600l }{ 600m }{ 600n }{ 600o }{--600p}{ 600r }{ 600s }{ 600t }{ 600u }{--600x}{--600z}{--600y}{--600v}| #610| <label>Subjects--Corporate Names: </label>|{\n6103 }{\n610a}{ 610b }{ 610c }{ 610d }{ 610e }{ 610f }{ 610g }{ 610h }{--610k}{ 610l }{ 610m }{ 610n }{ 610o }{--610p}{ 610r }{ 610s }{ 610t }{ 610u }{--610x}{--610z}{--610y}{--610v}| #611| <label>Subjects--Meeting Names: </label>|{\n6113 }{\n611a}{ 611b }{ 611c }{ 611d }{ 611e }{ 611f }{ 611g }{ 611h }{--611k}{ 611l }{ 611m }{ 611n }{ 611o }{--611p}{ 611r }{ 611s }{ 611t }{ 611u }{--611x}{--611z}{--611y}{--611v}| #630| <label>Subjects--Uniform Titles: </label>|{\n630a}{ 630b }{ 630c }{ 630d }{ 630e }{ 630f }{ 630g }{ 630h }{--630k }{ 630l }{ 630m }{ 630n }{ 630o }{--630p}{ 630r }{ 630s }{ 630t }{--630x}{--630z}{--630y}{--630v}| #648| <label>Subjects--Chronological Terms: </label>|{\n6483 }{\n648a }{--648x}{--648z}{--648y}{--648v}| #650| <label>Subjects--Topical Terms: </label>|{\n6503 }{\n650a}{ 650b }{ 650c }{ 650d }{ 650e }{--650x}{--650z}{--650y}{--650v}| #651| <label>Subjects--Geographic Terms: </label>|{\n6513 }{\n651a}{ 651b }{ 651c }{ 651d }{ 651e }{--651x}{--651z}{--651y}{--651v}| #653| <label>Subjects--Index Terms: </label>|{ 653a }| #654| <label>Subjects--Facted Index Terms: </label>|{\n6543 }{\n654a}{--654b}{--654x}{--654z}{--654y}{--654v}| #655| <label>Index Terms--Genre/Form: </label>|{\n6553 }{\n655a}{--655b}{--655x }{--655z}{--655y}{--655v}| #656| <label>Index Terms--Occupation: </label>|{\n6563 }{\n656a}{--656k}{--656x}{--656z}{--656y}{--656v}| #657| <label>Index Terms--Function: </label>|{\n6573 }{\n657a}{--657x}{--657z}{--657y}{--657v}| #658| <label>Index Terms--Curriculum Objective: </label>|{\n658a}{--658b}{--658c}{--658d}{--658v}| #050| <label>LC Class. No.: </label>|{ 050a }{ / 050b }| #082| <label>Dewey Class. No.: </label>|{ 082a }{ / 082b }| #080| <label>Universal Decimal Class. No.: </label>|{ 080a }{ 080x }{ / 080b }| #070| <label>National Agricultural Library Call No.: </label>|{ 070a }{ / 070b }| #060| <label>National Library of Medicine Call No.: </label>|{ 060a }{ / 060b }| #074| <label>GPO Item No.: </label>|{ 074a }| #086| <label>Gov. Doc. Class. No.: </label>|{ 086a }| #088| <label>Report. No.: </label>|{ 088a }| Posted by Paul Poulain Let me explain itemcallnumber. To define a "book", you need two different things: its classification => meaning what the book is related to. Many libraries use Dewey, but not all. Many use LCCN (not in France), or another classification (for example : AMS for mathematical libraries). its physical location in the shelves => the "call number". The difficulty here is that most libraries, and they are right, have call numbered their "books" like they have classified them. So, classification = callnumber. But that's not the same concept: a single book (= 1 callnumber) can have X classifications in some cases (= some subjects) X books can have the same callnumber, or different call numbers, even if they have a single classification (=when the library has a callnumber not 100% related to classification) That's why I introduced itemcallnumber in Koha 2.2 branch. We need a CLASSIFICATION at the biblio level and a CALL NUMBER at the item level! Usually they contain the same information, that's why there is a systempreference where you can say "OK, computer, automatically report subfield XXXy from biblio into item when adding an item."

Setting Operating Parameters Koha allows you to set various parameters to suit your library's needs. Some of these -- most notably the item types -- must be set before Koha can function. Others may be set later as needed for your particular library. We'll start with the parameters which control the operating environment of the library. In the next section, we'll deal with setting the parameters of your bibliographic data (which can be a very complex process).

Library Branches This parameter tells Koha about your library's public service outlets. Even if you have only one outlet, you need to give Koha some information about it. You may find that some information about your primary outlet already exists, since the installation script gives the installing technician the option of setting some basic information as part of the installation process. That information can now be changed or refined, if necessary. Begin by defining your branch categories. If, for example, you have one main library and several branch libraries, you might set up an "MAIN" (Main) category and a "BR" (Branch) category, with descriptions "Main library" and "Branch library."

Adding branch categories Now add the names and addresses, phone numbers, etc of your libraries in the "Branches" section. (All of your libraries should be described here, not just the branch libraries.) Give each library a unique and easily-remembered code (maximum of four characters). This code will be used in Koha's database to identify each library. When libraries are listed in Koha, they will be listed in alphabetical order by code. Until you set your branch the first time you use a computer to circulate items in Koha, the branch will default to the first library in the alphabetical code list -- be careful to set the branch the first time you use Koha or whenever you add a new computer! After you set the branch the first time, a cookie is stored on that computer so you will not need to set it again.

Adding branch descriptions Some libraries have also set up "virtual" branches with names like "At bindery" or "In storage" to make it easier to pinpoint the location of items that are temporarily not available. If you are going to do this, remember that these virtual branches will appear in the OPAC just as if they were real branches, and you will need to set your issuing rules for these branches accordingly. As you add branch categories and branches, the list on your "Branches" screen will grow. Make sure that each branch is assigned to a defined branch category, and you should be ready to go on to the next step.

Branches

Printers If you are going to be using a printer (or several printers) that is attached to your Koha server for producing statistical and operations reports, then you need to give each printer a name and tell Koha how to access it. You do this by telling Koha which print queue to use. In Linux, each printer configuration in your printcap file defines a print queue. The default print queue is "lp," but if you use more than one printer you will have other queues, probably with names like "text" or "postscript." Tell Koha which printer queue(s) you want to use for printing reports directly from the server.

Printers screen You can always print Koha screens directly to a printer attached to your workstation just by using your web browser's Print function. See the related comment in the User Comments section.

Item Types Item types are the "categories" into which your library items are divided. Defining item types must be done before Koha can function, and it should be done carefully and with a great deal of thought, because issuing rules, statistics, OPAC searches, and many other Koha functions will be based on these categories. You can define as many item types as you want. For instance, you probably want to have videocassettes in a different category from non-fiction books, and mysteries in a different category from children's picture books. If you already are using a commercial Integrated Library System, you almost certainly already have all of your materials divided up into such categories. Now you need to tell Koha what your categories are.

Adding Item Types The itemtype code is limited to four characters. This "Item type" code is rarely displayed by Koha; instead the "Description" of the type will be what users see. "Rental charge" is any amount you might charge to users for borrowing items of a certain type (like videos). "Number of renewals" specifies how many times a borrower of items of this type may renew the loan. "Not for loan" would be checked for item types such as reference materials which do not leave the library. Item types are useful for many things, and very important in controlling how Koha works. To cite just two examples: borrowers can limit their searches to items of a certain type; issuing rules are set according to item types (and borrower categories and branches). Setting up item types is one of the first things you should do after installing the Koha software.

Sample item types While some of your parameter settings may be delayed until after you have tested Koha for a while, item types are critical to the way Koha behaves and should be set early and carefully.

Borrower Categories Here is where you define the types of users of your library and how they will be handled.

Borrower category administration The borrower category administration page warns that you need a "C" (child) and "I" (institution) category. Koha will not fail if you do not have these category codes, but there are some features of Koha that expect these codes. The borrowing record of a "C," for example, will automatically be linked to the record of the child's parent. An "I" code allows the librarian to save information about the institutional borrower that is slightly different from the information saved about regular borrowers. If you do not want to have children's records attached to their parents records, and/or do not have institutional borrowers, you may ignore the warnings about these two special borrower categories.

Adding borrower categories Start by assigning a "Category Code" and a "Description" to each borrower type. The code is limited to no more than two characters and may be anything you choose. "Enrollment period" is a number indicating how many years a user's enrollment is valid. If your enrollments expire after four years, for example (as in a school?), then set this number to 4. If enrollments never expire, set this to an impossibly high number (99). "Upper Age Limit" and "Age Required" set the age parameters for this type of user. If you issue children's cards to users between the ages of 2 and 18, for example, then "Age Required" would be "2" and "Upper Age Limit" would be "18." If there is no upper age limit, set this value to 999 (the highest allowed). "Enrollment Fee" and "Reserve Fee" (if any) should be entered either as whole numbers or with six decimal places, with no currency notation (e.g. "1.250000" instead of "$1.25"). "Overdue Notice Required" lets you bypass generating overdue notices for this user type.

Issuing Rules Here is yet another important parameter to set before using Koha, since it controls many aspects related to the circulation of library materials. Item Types and Borrower Categories, however, must be defined before you can define your Issuing Rules. (Your branches should be defined, too, if your issuing rules will vary from branch to branch.) If you try to define issuing rules before item types and borrower categories are set, the grid at the bottom of the screen will be empty and you cannot proceed.

Issuing rules screen The on-screen help is pretty extensive for this parameter. The grid at the bottom of the screen contains the descriptions of all your item types (in the rows) and all of your borrower categories (in the columns), with each borrower column subdivided into boxes for issues and fines. In addition, the last row and the last column are both labeled with an asterisk. If a box in the grid is left blank, its value will be calculated based on the value in the "*" boxes, as explained in the "Default values" area of the on-screen instructions. Actually, the instructions regarding "Default values" should currently be ignored. Changes to Koha have broken the default values capability for the past few versions of Koha, including version 2.2.5. This should be corrected in the near future; meanwhile, you must be sure to fill in the values for every borrower category and every item type and every branch, or you will receive error messages when trying to issue items to borrowers. The "issue" boxes are filled with two whole numbers, separated by a comma. The first number tells Koha how many days a borrower from the corresponding category can borrow an item of the corresponding type. The second number tells Koha how many items of the corresponding type can be borrowed by a borrower from the corresponding category. In the screenshot above, an institutional borrower can borrow most items for 28 days, with an upper limit of 5 items of most types. Every other category of borrower can borrow most items for 21 days, with varying limits on the number of items of each type which may be borrowed. Koha will not accept an entry of "0,0" in these boxes, so if you want to block a certain category of borrower from borrowing a certain type of item, set one of the numbers to "1" and the other to "0." Each of the "fine" boxes in the grid contains three numbers separated by commas. Each number defines the fine, how many days overdue the item must be before the fine is assessed (and a first notice prepared), and how many days after that the fine is assessed again (and a second notice sent). For example, if you charge adults 1 dollar (or Euro, or whatever currency) for overdue videos after three days and add another dollar charge after another five days, put "1,3,5" in the box in the grid that aligns with "Adult" and "Video recording." If you charge adults 25 cents for overdue fiction books after a grace period of seven days and repeat the charge seven days later, then the entry in the corresponding box in the grid would be "0.25,7,7". After the first and second notice are given, Koha prepares a "final notice" after the number of days set by the final number in the grid and sets the charge to the maximum that you set in the "noissuescharge" system preference. Fines are calculated by the fines2.pl script, located in the misc directory. If your system administrator puts this script in crontab, set to run after midnight, fines will be calculated every night. You should review this script first, however, because you may well want to customize it to handle fines differently from the default Koha behavior.

Stop Words Here you should list all of the words you wish Koha to ignore when performing catalogue searches or building the keyword index. Normally, you will not want Koha to save keyword references to articles like "The" and "A" and other very common words. Saving keyword references to these words does not help to limit a search and will make the keyword index very large and "cluttered" with words that are not really useful. The "stopwords" list defines these unnecessary words for your installation. You must define at least one stop word, or Koha searches will crash.

Simple Stop Words List for English (Note that the box beside the "OK" button is a search box for longer lists that span several screens.) If you are proficient at MySQL, it is often faster and easier to find an existing stopwords list, edit it, put it in the correct format, and use the MySQL "Load Data Infile" command to import the list into the stopwords table. Many academic libraries in the USA publish their stopwords list on the Internet, or you can ask other Koha libraries if they would share their stopwords list.

Z39.50 Servers Koha comes with Z39.50 client software for searching other libraries' MARC records; this parameter defines the Z39.50 servers you want Koha to search. In Koha version 2.x.x, the Z39.50 client will not work if Koha is installed on Windows or Mac OS X. This should change with the release of version 3.0.0. Z39.50 is an international standard for searching and retrieving information from remote databases. In practice, it provides a way for libraries to search and retrieve records from other libraries. Z39.50 client software is often provided as a component of an integrated library system; the server software is much less common. Index Data of Denmark (http://www.indexdata.dk) provides many of the software tools used for Z39.50, and also maintains a list of Z39.50 servers around the world. In this area, you can define servers for searching. Be sure the servers you choose support the MARC format you have chosen in your system preferences. To add servers, you will need to know the domain name or IP address of the server, the port number to use, and the name of the database to access. Be sure to choose servers which deliver records in the proper MARC format for your Koha installation. If you have a login name and password for Z39.50 servers that do not accept anonymous connections, Koha will save your user ID and password in addition to the other information it needs to make a connection. (For anonymous servers, leave the userid and password fields blank.)

Z39.50 Servers Setup The other fields on the form control whether or not the server is automatically searched when you request a Z39.50 search (put a "1" in the "Checked" field) and the order in which it is checked. It is a good idea to be selective in choosing servers. Defining more than five or six checked servers may slow down your Z39.50 search results.

Book Funds If you have set your "acquisitions" system preference to "normal," you now need to give Koha some information about your materials acquisition budget. (If you chose "simple" acquisitions, ignore this parameter.) "Book Funds" are accounts that you establish to keep track of your expenditures for library materials. They may be used for any kind of materials (not just books) and should match the line items in your materials budget. For instance, if your library establishes a budget line for books, another for audiovisual materials, a third line for magazines, and a fourth budget line for electronic databases, then you would have four Book Funds. The process of setting up the funds involves two steps: naming the funds, and setting the budget.

Defining Book Fund Names Each Book Fund has a unique fund code, limited to no more than five characters, that identifies it. You should decide on your fund codes (e.g. something like BOOKS, AV, MAGS, DATA for the four book funds described above) and enter the code in the "Book fund" box, then a full name in the "Name" box. If a fund is restricted to use by one branch, you may also choose that branch from a pull-down menu containing the names of all the branches you have defined. The list of branch names available for selection is not affected by the IndependantBranches systempreference. Once you have set up a fund, you will see a link to a page for setting up the fund budget. Here you will enter the beginning and ending dates of your budget period and the amount of money in that particular budget line.

Setting Book Fund Budgets Do not use any kind of currency notation (like "$") or commas when entering the budget number. (Commas will be converted to decimal points.) You may set up several budgets for each fund, if you like, each budget covering a different time period. Your dates will not be saved correctly unless you have already set your date format in the System Preferences section of the Parameters page -- DO THIS BEFORE setting budgets.

Currencies Define the currencies you deal with here. You should at least define your local currency here, giving it a name (like US DOLLAR or EURO) and setting the "rate" at 1. If you do business with vendors who charge in a different currency, enter a name for that currency (e.g. PESO) and set the approximate exchange rate compared to your currency.

Currencies Setup Note that currency names are limited to 10 characters or less. The exchange rate is used to calculate the remaining balances in your materials budgets when you purchase materials using "normal" acquisitions.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Rachel Hamilton-Williams There are two sorts of printing you can do within Koha and depending on what sort of library you are running, you may not need them both. You can print anything you see on screen from your web browser like any other webpage. That just requires that your workstation (PC) has access to a printer either via your local network, or plugged directly into your PC. SO if all you want to do is print the things you see on screen then that is all the printing you need. To use this sort of printing you just go (In Windows anyway) File > Print > choose printer, and other options. If you use circulations (Loaning things), you have the option of Koha printing some files that you *Don't* see on screen. SO Koha can print slips to give to your borrowers, and it can print overdue notices. Koha prints those automatically so the SERVER (rather than your PC) also needs to know the path to send these files to a printer. That means the Printer needs to be "seen" by the server - so it has to either a network printer, OR it can be plugged directly into the server (depending I suspect on your server hardware). Either way however KOHA will need to be told the path to the printer, because you won't be doing that via a print dialogue box every time it prints. That path is what you put into the parameters option for printing. IF you DON'T circulate books/items, you won't need to setup network printing because I'm pretty sure that all the automatic printing is tied up in circulation.

Setting Bibliographic Data Parameters If you set your System Preferences to use MARC bibliographic data, the last set of parameters you need to define is by far the most complex and the most important. MARC bibliographic data is coded with markup tags in accordance with long and involved sets of rules, and each flavor of MARC has somewhat different rules. Because Koha can be used with more than one flavor of MARC, you need to spend some significant time telling Koha how to handle your particular MARC data. Koha also comes with some special MARC tools that can make your daily cataloging chores easier, but you also need to set the parameters for those tools before they can be used. All in all, there's a lot of work involved in setting the bibliographic data parameters, so be sure to allow yourself plenty of time, and consider setting these parameters with the assistance of the person(s) who will be doing your bibliographic cataloging. If you are not going to have the assistance of someone who has done MARC cataloging, then it is strongly suggested that you get familiar with the basics of MARC before you start. A good overview of MARC 21 cataloging principles can be found at http://www.loc.gov/marc/96principl.html, and a detailed discussion of MARC 21 bibliographic data tags can be found at http://www.loc.gov/marc/bibliographic/ecbdhome.html. For more information about UNIMARC, see http://www.ifla.org/VI/3/p1996-1/sec-uni.htm. This manual does not explain MARC. If you are not familiar with MARC tags, subfields, indicators, etc., most of this section of the manual will be meaningless to you. Take some time now and learn the basic principles of MARC cataloging.

Biblio Framework (MARC Structure) -- first look As has been mentioned, one of the most basic principles of Koha is flexibility: so far as it is possible, the Koha user should be able to control what Koha does and how it does it. This principle extends to Koha's handling of MARC, as seen by the fact that Koha allows you to select no MARC, MARC 21, or UNIMARC for your bibliographic data format. This means, however, that the user must give Koha very specific instructions on how to display MARC data, and how to link MARC data to Koha's database. Biblio Frameworks allow the Koha user to define several different ways of displaying a framework for adding MARC data to Koha. You do this by specifying which MARC tags you want to use and which you want to ignore in each framework. When Koha was installed, the installer had the option of downloading either a MARC 21 or a UNIMARC "database" (or no MARC database at all). If this was done, you now have a database table containing most of the MARC tags and subfields in current use for your preferred MARC "dialect." Now you will use the "Biblio framework" administration page to select MARC tags and tell Koha which tags you want to use in each framework.

Biblio Framework Page (as installed) You will always have a least one framework to define, which will be the default framework. Click on "MARC structure" to begin this process. (MARC 21 tags are used in all screenshots and examples in this manual.) The screen you now see lists MARC tag numbers and some basic information about each tag.

MARC tags The columns on this screen: contain the tag number; the name of the tag ("Lib" is an abbreviation of the French word "libellé"); whether or not the tag is repeatable (according to the rules of your chosen MARC dialect); whether or not you want the tag to be mandatory (according to your library's cataloging practice); columns for authorised values and editing subfields (both of which we will discuss elsewhere); an edit icon; and a delete icon. A pull-down menu at the top of the page allows you to switch between your biblio frameworks, and a "search" box next to it allows you to skip to a specific tag. If you are certain that you will never use a MARC tag, then you can delete it, but since this will not result in any appreciable improvement in performance, it is probably better to leave it. There will be tags you want to add, however. (The "Add Tag" button is at the bottom of the screen and cannot be seen in the screenshot above.) If you are using older MARC tags that are not in the list of tags supplied with Koha, then use this page to add them. Similarly, you will probably need to add the holdings tag you currently use, or at least check the subfield structure of the 852 tag if you use it for holdings. If you click on the edit icon, you will be able to change the values for each MARC tag.

Editing MARC Tags The values that can be changed on this screen are the name of the tag as it will be displayed in the librarian's interface ("Lib for librarians"), the name of the tag as it will be displayed in the OPAC, whether or not the tag can be repeated within a MARC record, whether or not it is mandatory, and finally, a pull-down menu (initially empty) of "Authorised" values. Since this is a feature that is not commonly found in an ILS cataloging system, now is a good time to interrupt the process of defining the biblio frameworks and discuss Authorised Values. You can define biblio frameworks without defining any authorised values, but if you wish to make full use of Koha's features, you will probably define authorised values as part of the process of defining the biblio frameworks, moving back and forth from the Biblio Framework screens to the Authorised Values screens.

Authorised Values Koha allows you to restrict the values that catalogers can place in some MARC tag indicators and MARC subfields, allowing only certain pre-defined "authorised" values. These authorised values are defined here.

Authorised Values Administration As an example, let us assume that your Koha installation is used by several libraries, and you use MARC 21. You might want to restrict the 850a MARC subfield to the institution codes for just those libraries. In that case, you could define an authorised values category (perhaps called "INST") and enter the institution codes as the authorised values for that category. (By the way, category names are limited to eight characters.) Once the 850a subfield is linked to the INST authorised values category in your MARC tag structure, catalogers must choose a value from the list you define here, and may not type in any other value. In other words, the catalogers could not type in the 850a field, but instead would see a pull-down menu. If the INST category was setup as it is in the screenshot above, then the pull-down menu would have two choices: "Athens County Library System" and "Nelsonville Library." Depending on which of these the cataloger chose, Koha would insert the appropriate authorised value into the MARC record -- "ONe" if the choice were "Nelsonville Library," for example. Koha automatically sets up authorised value categories for your item types and branch codes, and you can link these authorised values to MARC subfields when you set up your MARC tag structure. To go back to our discussion of editing MARC tags in the Biblio Frameworks, the authorised value allowed for a tag is the tag indicator pair. Many tags in MARC 21 should have both indicators set to the "undefined" character (#), so you could make an authorised values category called "indicatr" and enter an authorised value of "##" as the only entry. Then you could select the "indicatr" authorised value category when editing one of the tags that require undefined indicators. The real power of authorised values, however, is demonstrated when they are used with MARC subfields. So let's go back now to our MARC tag structure and look at the MARC subfields. Currently (in Koha version 2.2.3), the Authorised Values feature for tags is not functional -- it only work with MARC subfields. In some future version, this feature may be fixed, but if it proves to have only limited usefulness, it may also be dropped from Koha.

Biblio Framework (MARC Structure) -- subfields The MARC subfield structure that you define will determine how Koha behaves for your catalogers. Needless to say, it is probably a very good idea to involve them in this part of the parameterization of your Koha installation! To edit MARC subfields, navigate to the MARC tag structure administration screen and click on the "subfields" button. In our examples, we will start by clicking on the "subfields" button associated with MARC 21 tag 100, "MAIN ENTRY--PERSONAL NAME."

Subfield structure for tag 100 As you can see most of the subfields are ignored in this particular Koha installation. Subfield 100a, however, has quite a few constraints. If we move to the bottom of this screen, we find an icon of a folder opening. Click on this icon to open the subfield editing screen to see what the possible subfield constraints are and how to change them.

Tag 100 subfields (editing) The subfield editing screen is very busy, with a lot of features that are unique to Koha. We will examine each of these. The screen displays all of the subfields that can be used with a tag, so it can be quite long (as in this case). Looking at the section for "Tag 100, Subfield a," we first see a group of "MARC constraints." These determine how the information in the subfield is to be used by Koha. The "repeatable" and "mandatory" checkboxes will allow catalogers to repeat a subfield, or will cause Koha to issue an error warning if the cataloger leaves a mandatory subfield empty. "Search also" is an interesting feature that allows a catalogue search to check several MARC subfields at the same time. In this example, a catalogue search for a certain author will check first for the author's name in subfield 100a of all MARC records, but will also check in 700a (in case the name is an added entry), and in 110a and 710a (in case the "author" is an organization). You could add more subfields here -- perhaps 511a, in case the "author" is actually a performer -- by typing them in the text field, enclosing each subfield identifier in single quotes and separating them with commas. The parenthetical "example for 200a" refers to UNIMARC tag numbers. The "Koha link" constraint requires some background explanation. Koha was originally written without any provision for using MARC records, and may still be used without MARC records. This is possible because the "original" Koha keeps basic bibliographic data in database tables and fields that were designed by the original developers of Koha. Since the time when MARC capability was added to Koha, the developers have referred to these tables and fields as the "original Koha database" and called the MARC records and MARC structural data the "Koha MARC database." Many of the simple tasks and searches that a library performs in the process of checking books in and out are still more efficiently managed by the original Koha database. So as you are building your MARC structure, you must tell Koha which MARC subfield data should be automatically loaded into the original Koha database, or Koha will not work. When you fill in the "Koha link" constraint, you choose from a pull-down list of all the tables and fields in the original Koha database, presented in the form "table.field." The table names are not that important for purposes of establishing your Koha links; the field names should be sufficient to help you decide which links are appropriate. Only one MARC subfield can be associated with an original Koha field. This means two things: 1) you must use the "Search also" constraint if you want simple searches to look in more than one MARC subfield, as we have with MARC tag 100a; and 2) most of your MARC subfields will not be linked to an original Koha field -- there are many more MARC subfields than original Koha fields. The "Editor constraints" section mostly controls how this subfield is presented to the catalogers. The "Text for librarian" and "Text for OPAC" will be the descriptive name of this subfield in the librarian's interface and the public catalogue respectively. The "Managed in tab" constraint allows you to choose from a pull-down list with the values "ignore," numbers "0" through "9," and "items (10)." "Tab" is not the keyboard "tab" used for indenting text; in this case, "tab" refers to a tab like you would find on a manila file folder, or in a web browser that supports tabs. It allows you to subdivide the MARC tags and subfields the catalogers will be using into several browser tabs, so the cataloging web page will not be too long. Ignored subfields simply do not appear at all, while subfields "managed in tab 0" will appear in the first tab, subfields "managed in tab 1" will appear in the second tab, etc. (Numbering things beginning with "0" instead of "1" is a convention of computer programming.) For instance, you might choose to put all of the MARC subfields associated with the MARC 21 number and classification tags 010 to 088 (except for the subfields you want to ignore) in tab 0, all main entry tag subfields (tags 100-130) in tab 1, etc. This will keep the cataloging web page more manageable. Koha currently does not use data from any MARC tags below 010, but you can define tags below 010 and use them to store data from imported MARC records. Koha can also calculate a Leader for your MARC records -- see the section on plugins for more information. See the related comments in the User Comments section. The "items (10) tab" is reserved for subfields that only contain item information. The items information appears on a separate screen from the rest of the basic MARC bibliographic record in Koha, since items are managed separately from the rest of the bibliographic record; libraries routinely add or delete item information from MARC bibliographic records, as extra copies of library materials are added or removed from the collection. Koha requires that one -- and only one -- MARC tag will be linked to the original Koha "items" table. Some of the fields in the items table are meant to hold data indicating the current status of an item, and will not be linked to the MARC record. Other important data will come from your MARC "holdings" tag: items.barcode, items.dateaccessioned, items.homebranch, items.price, and items.itemcallnumber are good examples. So whatever MARC tag you use for your holdings information (whether it be 852 or 9xx, or whatever) should be "managed in tab items (10)" -- and that should be the only MARC tag managed in that tab -- and it should be linked to the appropriate fields in the original Koha items table -- and be the only MARC tag linked to the items table. If you manage more than one MARC tag in the items tab, or link more than one MARC tag to the items table, Koha will not work. The "hidden" and "URL" checkboxes have pretty clear on-screen explanations. If the "hidden" box is checked, the subfield will be used by Koha, but never seen by the catalogers. Instead of manually filling such a subfield, Koha will follow instructions from the "default options" to fill the subfield. The "URL" checkbox simply tells Koha that the content of this subfield should appear as an active hyperlink when the record is displayed in the catalogue. The "Default Options" section allows you to use several unique features of Koha to fill subfields with default values. We will look closely at each of these features in the next sections. None of these options must be used -- they are truly "optional" -- but they can make some of your cataloging chores simpler. Note the warning on the screen -- you cannot choose to use more than one type of default option for a given subfield. Once you have completed editing your subfields, you will have completed the most difficult and time-consuming part of preparing Koha for use. You are almost done!

Authorised Value We have already discussed authorised values in the context of MARC tags, but their most important use is with subfields instead of tags. If you choose a category of authorised value from the pull-down list, then the only values that the catalogers can enter into this subfield will be values they choose from that category. Even if you have not defined any authorised value categories, you will have two automatic pull-down choices: "branches" and "itemtypes." You can prevent the catalogers from manually entering branch codes and item types in subfields of your holdings tag by choosing one of these authorised value categories. For example, as you are setting the structure for your holdings tag, you can set up a subfield meant to contain the branch location of an item so that it pulls an authorised value from the "branches" category. Then as catalogers are adding holdings to your catalogue, they will find a pull-down list of all your branch names in this subfield; they will only be able to choose a name from this list, and cannot type in anything else. If you also link this subfield to items.homebranch or items.holdingbranch, you will always be able to accurately track an item's location. You must use the "itemtypes" authorised values for at least one of your MARC subfields and then link that subfield to biblioitems.itemtype. You must have two subfields in your MARC holdings tag that use the "branches" authorised values, and those two subfields must be linked to items.homebranch and items.holdingbranch. (The holding branch value in the items table will change as an item is transferred from branch to branch, but it still must have an initial value set when an item is cataloged.)

Thesaurus Koha's "thesaurus" feature is a way to use MARC authority records -- not to be confused with Koha's "authorised values" -- to make sure only standardized names, titles, etc. are used in your catalogue records. There will be much more detailed discussion of authority records in a later section ("Thesaurus Structure"); this section will provide only a basic overview of how to activate this feature. If you wish to provide access to authority records for a given subfield -- MARC 21's 700a subfield, for instance, to make sure an author's name is available in an added entry in its approved form -- you will need to create a subfield "9" for that tag (e.g. tag 700, subfield 9) by adding it at the end of the subfield editing screen.

Adding subfield 9 Koha uses subfield 9 to store the link between a bibliographic record and an authority record. Make sure this subfield is managed in the same tab as the other managed subfields for this tag, and then click the "hidden" checkbox so it will not be displayed with the rest of the record. Go to the subfield that will hold the value you want to standardize (e.g. 700a in MARC 21 for an author's name). For this subfield, choose an appropriate thesaurus category (that you have created in your Thesaurus Structure) from the pull-down menu -- perhaps category "PN" ("Personal Name"). Now when the catalogers are adding a record, they will see three dots (...) after the textbox of the 700a subfield. Clicking on these dots will open a pop-up window allowing the cataloger to search your authority records for a standardized version of the author's name. If the desired name is found in your authority records, it can be automatically copied into the 700a subfield. (If the desired name is not found, the cataloger can enter the name manually.)

Plugins Plugins are small computer programs (Perl scripts, to be exact) which can be used to calculate the value of a subfield. To date, most plugins that are available as part of the Koha code deal with UNIMARC fields, but a programmer could create a custom plugin to do anything you want. For example, you might want to create a plugin that would take the MARC 21 Library of Congress Control Number (subfield 010a), add your organization code to the beginning, add a cataloger-defined character at the end, and save the result as your System Control Number (035a). A programmer could create this plugin for you, name it something like control_numbers.pl, and save it with your other Koha code. Then as you are editing your MARC 21 subfield 035a, you could choose the control_numbers.pl plugin from the pull-down list. The Koha plugins are stored in your Koha intranet/cgi-bin directory, in the subdirectory value_builder. Now (in our theoretical example) when the catalogers are adding a record, they would see three dots (...) after subfield 035a. Clicking on these dots would open a pop-up window that asks the cataloger to enter the special character to be added to the end of the LC Control Number; the plugin would then use the value already entered in 010a, your organization code, and the special character to construct the System Control Number and insert it into the subfield. The cataloger would always have the option of changing this value, or simply entering the System Control Number manually instead of using the plugin.

Leader plugins Beginning with version 2.2.4, Koha comes with special plugins for building Leader information for MARC records. The Leader is a fixed field at the beginning of each MARC record that contains coded information for the processing of the record. It does not have a number, as the other MARC tags do -- it is simply the "Leader." Koha has no need for Leader information and does not use it. However, Koha can store Leader data, and can help you build your own Leader data. Here is how: When setting up your Biblio Framework, add a tag 000 and call it "Leader" (or whatever you wish to call it). In this 000 tag, create a subfield "@" and name it "leader" (or something). This @ subfield will be the subfield that stores the Leader data. If you are importing MARC records directly into Koha, you can now store the Leader in this 000 tag and @ subfield. If you wish Koha to help you build Leader data for MARC records you create with Koha, select the plugin marc21_leader.pl (for MARC 21) or unimarc_leader.pl (for UNICODE) for the @ subfield. When you create (or edit) bibliographic records, clicking on the three dots following the tag 000@ field will open a pop-up window to guide you through the creation of your MARC Leader.

Leader pop-up window Make the appropriate choices from the pull-down menus, and Koha will create the encoded Leader data and insert it into your 000@ subfield. You now have Leader data stored with your records, should you ever need it for some other application.

Link A link is somewhat like a simplified plugin. If you have two MARC subfields that will always contain the same value -- for example, the two subfields in your holdings tag that will store home branch and holding branch for a system that has only one branch -- then you can link the second subfield to the first and the value will be automatically entered into the second subfield as you enter it in the first.

Koha to MARC Database Links This page provides a simplified way to map your MARC tags and subfields to the "original" Koha database tables. This can also be done while setting the MARC tag structure, as we have seen, but it is easier to see the relationship between the MARC database and the Koha database here.

MARC to original Koha links The pull-down menu at the top lists all the Koha tables that can receive values from the MARC records. The columns from each table are listed in the area below the pull-down menu. Do not expect to have every Koha table.column mapped to a MARC subfield. Some (such as biblionumber, biblioitemnumber, and itemnumber) are values generated by Koha and will probably be automatically mapped. Others are flags which are set in the course of normal circulation activities and will contain information that is not part of your MARC record. This is a one-to-one mapping. In other words, a MARC tag/subfield can be mapped to one, and only one, Koha table.column. MARC data that is not mapped to a Koha table does not disappear -- it is simply not available for display on circulation screens and on some search results screens.

MARC Check Once you have completed the process of setting up your default Biblio Framework (MARC structure) and have reviewed your Koha-MARC links, click on this link to activate a small program that checks for major errors in your MARC setup.

Checking MARC setup This MARC check does not guarantee that you will like the first results of your efforts to set up your MARC displays, etc. -- it simply checks for major errors. You will probably revise your MARC setup several times before you are completely pleased with it. Be sure to run this program after every revision.

Thesaurus Structure Catalogers often rely on MARC authority records to keep personal names, place names, subjects, etc. standardized across a catalogue. For example, if you have several books by the late Pope in your collection, the bibliographic records you import from other sources may have the author's name in a variety of forms: "John Paul II, Pope, 1920-2005"; or "Joannes Paulus II, Pope, 1920-2005"; or "Juan Pablo II, Pope, 1920-2005"; or "Jean Paul II, Pope, 1920-2005"; or "Johannes Paul II, Pope, 1920-2005"; or "Joann Pavel II, Pope, 1920-2005" to name some of the many possibilities. But you want all of the books to be displayed whenever a catalogue user searches for "John Paul II." To do this, you modify the bibliographic records so they conform to an authority record that specifies the "correct" form of the name as "John Paul II, Pope, 1920-2005." Individual catalogers almost never create their own database of authority records, but instead buy or download authority records from a trusted source. These authority records have their own MARC structure, which looks somewhat like a simplified MARC bibliographic record structure. If you have access to such a database, you can setup Koha's Thesaurus Structure to allow you to retrieve values from the authority records as you create or modify your bibliographic records. When you select "Thesaurus structure" from the Koha parameters page, you will see this screen at first:

Thesaurus administration (unchanged) The Koha installation process offered the opportunity to install a default authority record framework for MARC 21 or UNIMARC. If this was done, you can click on the "MARC structure" button for the Default framework and see the structure that has been setup for your authority records:

Authority record structure (MARC 21) If you are using a different flavor of MARC, you will need to define the authority record structure manually, or modify the MARC 21 or UNIMARC structure to conform to your MARC flavor. The SQL statements to create the default framework, if it was not created during the installation process, are stored in your Koha intranet directory in the sub-directory scripts/misc/sql-datas. Otherwise, you should have no need to modify any of the default framework, unless you intend to create your own authority records. You now need to define some authority types by clicking on the "Add authority type" button at the bottom of the administration screen. As an example, we will set up an authority type to be used for personal names, using MARC 21 authority and bibliographic tags.

Personal name authority type The "Authority type box" accepts a code for this authority type. For personal names, you could use "PN." The "Description" is the term that will appear in some pull-down menus and is purely for information -- in this case it explains what "PN" means. The "Summary" textbox holds the list of authority record subfields which will be displayed when the cataloger accesses the authority records to look for a match for a personal name in a bibliographic record. (Displaying the entire authority record would result in a display that would be too big to be useful.) Each subfield should be enclosed in square brackets. In our example, a search of the authority records for a personal name will display the MARC 21 personal name heading tag (100), using both the subfields that hold the regular form of the name (100a) and any fuller version of the name (100q). The search will also display the "see from" tracing tag (400) and the "see also" tracing tag (500). (For personal names in UNIMARC, you might use "[200a][200b][200c] [400a][400z] [100a]") The display of the summary of the authority records in the search results list would thus contain the heading field, the "see from" tracing fields, and the "see also" tracing fields. You might also consider setting up the display to give you more information, such as adding subfields 100b, 100c, and 100d to the list so you can see more information about an author. If you include all of these subfields on the same line with your 100a subfield in the "Summary" box, they will appear on the same line in your search display. The "Report tag" is the authority tag from which a value will be retrieved and "reported" back to the bibliographic record when the cataloger selects an authority record from a search results list. Our Thesaurus Structure screen now looks like this:

Thesaurus administration (modified) You can continue to add other authority types for place names, organization names, etc. The code for every authority type you define will automatically appear in the "Thesaurus" pull-down list when you setup your Biblio Frameworks. To follow along with our example, let us assume that you have a database of authority records, you have defined a "PN" authority type as above, and have defined a (MARC 21) Biblio Framework with a subfield "9" defined (for holding the link to an authority record) and with the "Thesaurus" value for subfields 700a, 700b, 700c, and 700d set to "PN." In your authority records database, you have the following record:040 $b eng 100 0# $a John Paul $b II, $c Pope, $d 1920-2005 400 0# $a Joannes Paulus $b II, $c Pope, $d 1920-2005 400 0# $a Juan Pablo $b II, $c Pope, $d 1920-2005 400 0# $a Jean Paul $b II, $c Pope, $d 1920-2005 400 0# $a Johannes Paul $b II, $c Pope, $d 1920-2005 400 0# $a Joann Pavel $b II, $c Pope, $d 1920-2005 510 2# $a Catholic Church. $b Pope (1978-2005: John Paul II) 700 04 $a Juan Pablo $b II, $c Papa, $d 1920-2005 $7 aacr//spa 700 06 $a Jean Paul $b II $c pape, $d 1920-2005 $7 aacr//fre 700 04 $a Jean Paul $b II $c (Pape), $d 1920-2005 $7 ncafnor 700 04 $a Johannes Paul $c Papst, $b II $7 rakThe cataloger is working with a bibliographic record for a book written by "Joannes Paulus II, Pope, 1920-2005" and wants to add an entry to the bibliographic record with the authorized version of the name in English. The cataloger would go to the 700a subfield in the bibliographic record and click on the three dots (...) that appear after the subfield because this subfield has thesaurus access enabled. A search box pops up and the cataloger can perform a search for the name as it appears in the bibliographic record to find any matching entries in your authority records.

Authority record search Clicking on the curved arrow in the "Get It" column will retrieve the values in the authority record and insert them into your bibliographic record. Any of your subfields which have the thesaurus option enabled will be modified with the values in the "Report tag" you set up in your Thesaurus Structure. In our example, we asked for the contents of tag 100 to be "reported," and we enabled the thesaurus option for subfields 700a, 700b, 700c, and 700d. So clicking on the arrow inserts the value from 100a into 700a, 100b into 700b, etc. Not only that, but because the 700 tag in this particular bibliographic record is now linked to this particular authority record (through subfield 9), this bibliographic record will be automatically modified if this authority record is ever modified. Establishing an effective link between authority records and bibliographic records will require that you spend a lot of time working back and forth between your Thesaurus Structure and your Biblio Frameworks. But for libraries that have a database of authority records, the thesaurus is a very powerful cataloging tool!

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Thomas Dukleth Fixed fields and control fields without subfields can be created in the Koha MARC frameworks by creating a field with whatever field name is needed and creating a subfield with '@' as the subfield identifier. Koha will treat these special subfields as fields without indicators even if the record editor shows unused blank phantom indicators. The leader is field 000 with subfield '@'. If fields 000 to 008 are missing from Koha MARC frameworks, the user can add them along with any other omissions in the Koha framework editor in Koha System Administration. Fields and their subfields will appear in the MARC views and the record editor if their subfields or '@' pseudo subfields are set to managed by Koha in the MARC framework editor. To have them appear in the detail view requires editing the templates. Subfield order will be simple alphabetic order unless you hack Koha significantly or wait for version 3.0. Collective field indexing can be provided for any field/subfield by providing field and subfield linking in the search also text box in the MARC framework editor. This collective field linking is not compliant with searching several indexes separately in accordance with the structure of the bibliographic record, but it is much faster. Record indexing will run from a different database design in version 3.0.

Tools At the end of the Parameters page are a few items that are not parameters at all, but are instead utility programs that can be very helpful in certain situations.

MARC Biblio Export This is a tool for exporting your bibliographic records in standard MARC communications format (ISO2709).

MARC Export Although the screen warns that it exports only the basic bibliographic information with no holdings information, any holdings information originally loaded into Koha when the record was added will be included in the exported record. You are asked to provide a starting biblio record number and an ending number for the export, or you can specify that you want to limit the export to a specific number of records, starting with the first (useful for testing a small export before doing a large export). Within these number parameters, you may also select records based on item type, home branch, or call number. If you want to export all of your records, leave the start and end numbers and all other criteria blank. Records are downloaded to the workstation that requests the export and are saved in a file called marc.pl (not to be confused with the Perl script of the same name found in /usr/local/koha/intranet/cgi-bin/export) which on Linux systems is usually saved in the /tmp directory.

<anchor id="MARCimport" />Upload MARC Records into Reservoir This tool allows you to load a file of MARC records in MARC communications format (ISO2709) into Koha's reservoir of incomplete records (i.e. without holdings information).

MARC import The reservoir is an unusual feature of Koha. Libraries can keep a collection (reservoir) of basic MARC records which they have collected from other sources, either through Z39.50 searches or by using this tool to load files of MARC records obtained some other way. When cataloging, these records can be pulled from the reservoir and used as the basis for new records, with added holdings information, that will be saved to the catalogue of active records. As the screen explains, there are several options that can be set when using the import tool. When the import is finished, you will see a report of how many records were added to the reservoir and how many were skipped (and why). See the related comments in the User Comments section.

Generate Barcodes This utility can be used to print barcode labels for your library items. To use it, you must have the 0.3r77 release of the PDF::API2 Perl module loaded on your computer (and have an appropriate printer attached to your computer, of course). Check with the person who installed your Koha software to be sure you have the correct version of PDF::API2. When this is done, you can generate barcodes:

Generating barcodes This page can be confusing the first time you see it. You can choose to print either a single barcode or a range of barcodes -- but you can only print barcodes for items which have already been added to your catalogue. (You cannot use this tool to print a range of barcodes for items you will catalogue in the future, for example.) You should select your country code from the pull-down list. Note that the barcode symbology that will be printed is EAN128, a fairly common type of barcode world-wide. The paper size is set by your printer configuration -- more about that in a moment. And there is a text box if you want the same text to appear under each barcode (such as the name of your library) -- if you leave the text box blank, the title and author of the matching item will be printed under the barcode. The grid at the bottom of the page tells your printer where to begin printing on the page. If you have a sheet of self-adhesive barcode labels, five labels across the sheet, and you have already used three labels, you want the printer to start printing at the position of the fourth label, so you would click the radio button beside "Label 4." Margins for the labels, the number of labels on a page, and some other parameters are controlled by your printer configuration, which can be modified by clicking on the "Go to Printer Configuration" link.

Printer configuration (barcode labels) From this page you can set the parameters for your sheets of labels, including label size, number of labels across each sheet, number of rows of labels per sheet, sheet size (A4, Letter, or Legal), and the margin around each label. The "System dpi" is not your printer DPI, but rather the DPI resolution of your computer -- typically 96, except on some newer computers which may support screens with higher resolutions (such as 192). When these parameters have been set, click the button to save your settings and return to the Barcode Generator screen. When everything is ready to go, click the "Generate Barcodes" button. Koha will generate a PDF file of your barcodes and display them on your screen -- use your browser's print function to send the file to your printer. Currently, the barcodes generator works best with 11-digit barcodes. The last few digits of longer barcodes will not be printed under the barcode itself, and shorter barcodes will have the check digit printed after the barcode number. You should have a Perl programmer alter the Koha code for you if you wish to use something other than 11-digit barcodes.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Thomas Dukleth I advise against using the current Koha web browser interface administration tools for importing MARC records if you want complete and/or valid records. Any deficiency in your System Administration : Biblio Framework will result in fields and subfields missing from the biblio framework being dropped from records imported through the Koha administration web interface. You could add the missing fields and subfields to correct for this problem but some time should be taken to audit the existing default framework. This is true for System Administration : Import. This is also true for the Koha Z39.50 client. Import MARC records into Koha in batches using bulkmarcimport.pl to import the records. The Unix default path is /usr/local/koha/intranet/scripts/misc/migration_tools/bulkmarcimport.pl in Koha 2.2.4. Be certain to set the proper values for the environment variables PERL5LIB and KOHA_CONF before running the script.

General Notes on Using Templates Koha makes extensive use of the HTML::Template Perl module to build the web pages that are presented to the Koha user. There are two good reasons for this: the look of Koha can be changed by rewriting only the templates, changing nothing in the Perl code itself; and there is a tool to translate templates, so it is possible to translate Koha to new languages without too much trouble. Templates are one of the reasons why Koha is so flexible and adaptable, because they allow anyone with a basic knowledge of HTML to change the look and feel of Koha, or even add and remove information from display pages. To find the templates that are installed with Koha, look in the directories in the path where you installed Koha (often /usr/local/koha on Linux systems) called intranet/htdocs or opac/htdocs for the librarian and OPAC templates respectively. For example, the template for the web page used to add books to a virtual bookshelf is found at /usr/local/koha/opac/htdocs/opac-tmpl/css/en/opac-addbookbybiblionumber.tmpl and looks like this:  <div id="mainbloc"> <h1>Add book to bookshelf</h1> <label>Title</label> <label>Author</label> <h2>Select bookshelf</h2> <form> <label>Add to virtual shelf</label> <h2>or add to a new bookshelf</h2> <input type="text" name="newbookshelf" maxlength=40 size=40> <input type="hidden" name="biblionumber" value=""> <select name="category"> <option value="1">Private</option> <option value="2">Public</option> <option value="3">Free</option> </select> <input type="submit" value="Add to virtual shelf" class="button catalogue"> </form>  When this template is actually used to build a Koha web page, the resulting page source might look something like this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>popup</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <link rel="stylesheet" type="text/css" href="/opac-tmpl/css/en/includes/opac.css" /> </head> <body>  <div id="mainbloc"> <h1>Add book to bookshelf</h1> <label>Title</label>The dark tower vii : <label>Author</label>King, Stephen. <h2>Select bookshelf</h2> <form> <label>Add to virtual shelf</label><select name="shelfnumber" size="1"> </select> <h2>or add to a new bookshelf</h2> <input type="text" name="newbookshelf" maxlength=40 size=40> <input type="hidden" name="biblionumber" value="3"> <select name="category"> <option value="1">Private</option> <option value="2">Public</option> <option value="3">Free</option> </select> <input type="submit" value="Add to virtual shelf" class="button catalogue"> </form> </body> </html> Once you have looked at some of the Koha *.tmpl files, you should read some documentation on HTML::Template to learn how to change them. Three good web sites explaining HTML:: Template are http://www.perldoc.com/perl5.6/lib/HTML/Template.html, http://www.sitepoint.com/article/introducing-html-template, and http://html-template.sourceforge.net/article.html, and there are many other sites as well. Note that future versions of Koha will move to using standardized prog templates, with the goal of having templates that are simple, are XHTML valid, and can be configured using cascading style sheets. This will require that new templates follow some basic rules: Templates should always begin with <!- - TMPL_INCLUDE NAME="doc-head-open.inc" - ->Koha - - TEMPLATE_TITLE <!- - TMPL_INCLUDE NAME="doc-head-close.inc" - -> <!- - TMPL_INCLUDE NAME="menus.inc" - -> <!- - TMPL_INCLUDE NAME="menu-MODULE.inc" - -> where MODULE is one of the Koha modules (catalogue, acquisition, etc.) Templates should always end with <!- - TMPL_INCLUDE NAME="intranet-bottom.inc" - -> Use <div id="TEMPLATENAME_what_this_block_does"> </div> for each logical block. For example, if a page contains one block for borrower information, one for borrower fines, and one for borrower reserves, it is a good idea to have three different blocks. (Usually a block begins with an <h2> header.) All action buttons inside a block are enclosed in a <div id="action"> </div> and placed at the end of the block. Avoid having more than one action div. Use <h1> for the page main title. Use <h2> for the block level title. Construct forms with <label>text</label><input type="..."> NOT with <table>. Use <table> as seldom as possible (and only where tables are truly useful). Do not use <caption> at the beginning of tables, at least not for the table title. Since most blocks are not tables, the caption does not exist everywhere. Use <h2> instead.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Owen Leonard Koha's templating system allows you to have a great amount of control over the interface, but it's not always easy to get started. The template files (*.tmpl, *.inc) are used by Perl's HTML::Template to create the HTML files that are returned to the user. The template files are not straight HTML, which is why applications like Dreamweaver can't handle them. Dreamweaver wants to try to build a dynamic preview of the template file and it can't because the template file contains not only HTML markup but also  tags which control the output. If you want to get your hands dirty and to some template editing, the best option is to use a text editor. Someone suggested HTML-Kit, which would work fine. It doesn't do syntax-highlighting for .tmpl files by default, but you can tell it to. To start working, pick one of the current templates to customize (default or npl in the intranet, css or npl in the OPAC), and copy all the files to a new folder. Then go into Koha's system preferences and change your template to the new one. That way you'll still have the originals to fall back on if something breaks. One confusing thing about a lot of the templates is that one template will handle several different situations depending on what action the user has taken. So the whole structure of the template might be wrapped in conditional tags:  [ some HTML code here ]  [ some HTML code here ]  Use the standard HTML markup on the page to give you clues as to what's going on and where you are in the template, comparing it to what you see on the screen running Koha.

The Online Public Access catalogue -- to be completed General description -- To be completed

Searching To be completed

Requesting Reserves To be completed

Updating Member Information To be completed

Biblio Baskets To be completed

Virtual Shelves To be completed

Purchase Suggestions To be completed

Circulation Tasks The basic function of a lending library is (of course) to lend materials to borrowers. The Koha circulation module handles the daily tasks of keeping track of which borrower has which materials, when the materials are due back, what late fees might be due, and so forth. This is the part of Koha which the librarian(s) will use most often.

Issues Issues ("checking out") and returns ("checking in") are the basic tasks involved in circulation of library materials. In fact, you can perform these two basic tasks from the Koha home page, without going to the circulation page:

Basic circulation from the home page As you can see, starting the process of issuing an item can be accomplished from the home page by typing or scanning the borrower's card number in the "Issue" box. Likewise, items can be returned by scanning or typing the barcode on the item in the "Return" box. Normally, however, library staff will probably work from either the circulation issues or returns pages instead of the Koha home page. The issues page is the one that opens when you click on "Circulation" from the home page:

Circulation issues page This page offers the opportunity to "Change Settings" before you begin work. It is particularly important that the branch be set correctly before starting to issue materials. If the branch is set to "Main" and you are actually issuing from "Branch1," all circulation statistics will be credited incorrectly to "Main" and Koha will assume that the item was located at "Main" instead of "Branch1." The branch setting is the way Koha determines where the transaction is actually taking place. Note that you do not need the borrower's card number if you know the borrower's name. If you enter any part of the borrower's name (any name -- but last name works best), then Koha will retrieve a list of possible borrowers from which you can choose. For example, if you had entered "hed" you might see a display like this:

Name list If you select a name from this list, or type in a name or card number that identifies only one person in the database, you then see a screen showing borrower information.

Borrower details Now you are ready to get to work! This screen allows you to do a number of different tasks. (This, by the way, is the screen you will see if you scan a borrower's card number from the Koha home page.) First of all, it allows you to check out an item. This is done by scanning or typing the item barcode in the "Item Barcode" box and either clicking on "Issue" or pressing the return (enter) key on the keyboard. (Many barcode readers can be programmed to automatically add a "return" to the end of the barcode.) This screen also allows you to change the due date for an item to a special due date; this is done by using the date pull-down menus below the barcode box before you enter the barcode number. If you want your special due date to apply to all of the items the borrower is getting, then you can check the "Sticky Due Date" box and all items subsequently issued to this borrower (during this session) will be due on that date. Before describing what happens after you enter a barcode, note that there are two buttons beside the borrower's name: "detail" and "edit." Clicking on these buttons will either show you more details about the borrower or allow you to edit the borrower's details. (This assumes that the staff person has permission to add or modify member records: if this permission has not been granted, clicking on "edit" displays a screen with the message, "Sorry, Koha doesn't think you have permission for this page.") The process of editing or adding member records will be discussed in a later section of this chapter. It is possible that you will see special messages, located at the bottom of the Borrower Information box, alerting you to problems with the borrower's account. These messages might be prompted by circumstances such as: this borrower has overdue items on their account (as in the screenshot above) this borrower has a debt or a credit with the library (perhaps from overdue fines or lost items) this card has been reported as lost this borrower has been debarred (barred) from receiving library services this borrower has an incorrect address on file with the library this borrower has reserved items waiting for them at the library library staff have attached any other special note to the borrower's record Assuming that you have set any special due date and have dealt with any special circumstances with the borrower's account, you are now ready to scan or type in the Item Barcode. Koha checks to see if there are any problems with issuing this item before it completes the transaction; if there are problems, a prominent message is displayed.

Item problem message This problem resulted from scanning in the barcode of the first item in the list of "Previous Issues," prompting Koha to ask if we really wished to renew the loan. There are a number of conditions which will result in a message from Koha while issuing items, some related to the borrower, some related to the item. One type of condition results in Koha asking for confirmation before proceeding, as in the example above: the borrower owes money to the library the borrower would have too many items checked out this item is already checked out to this borrower (hence a renewal) this item is currently checked out to a different borrower this item has been reserved by another borrower Another type of condition results in Koha simply reporting that the item cannot be issued: this borrower has been debarred (barred) from receiving library services this card has been reported as lost this borrower has an incorrect address on file with the library this borrower's registration has expired the sticky due date is invalid the barcode is unknown the item is classified as "not for loan" the item has been previously withdrawn from the collection the renewal limit has been reached library staff have restricted issuing of this item for some other reason Once all of the error conditions have been satisfied, the item is issued:

Item issue The most recently issued item now appears at the end of the list, with its (new) due date.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.)

Returns Returning items is simply a matter of scanning or typing the item barcode in the "Item Barcode" box.

Returns As you can see from the screenshot above, returning an item produces a display of information about the account of the borrower. If certain conditions exist relating to the returned item, you may also see alert messages. Some of the conditions which produce a message are: the item is overdue and a fine has been assessed the item was previously reported as lost (and a fine may have been paid) another borrower has placed a reserve on this item It is worth noting that Koha saves information about the previous two borrowers of an item. This information is useful when a borrower returns an item because it was damaged by a previous borrower. This information can be accessed by searching for an item through the librarian interface, as explained in a later section of this chapter.

Branch Transfers From time to time the library may want to send a group of items from one branch to another. When this is done, the catalogue must be updated to reflect the new location of the items. While it is possible to do this simply by returning all the items when they arrive at the new location (and ignoring the warning messages that the item was not on issue), Koha also includes a separate "branch transfer" utility to change the holding location in the catalogue. This utility is quite simple and straightforward.

Branch Transfers Set the name of the branch where you are sending the items, then scan or type in each item barcode. The utility does not display any list or information about the item(s), it simply changes the holding location. To return to issuing items, click on "Next Borrower," or click on "Returns" to resume returning items.

Reserves Pending Koha will inform you of pending reserves on items as they are returned, but if you would like to see a complete list of all pending reserves, select "Reserves pending" from the "Circulation" pull-down menu:

Reserves Pending "Priority" shows which reserve will be filled next when there are multiple reserves on one title; the priority "1" reserve will be the first one filled. "Location" is the place where the borrower would like to pick up the reserve, and "Notes" are optional. Clicking on "Sort" will sort the list by reserve date, patron (borrower), or title. If your borrowers are active users of the reserve function, be careful with this report; it can become so long that it will crash your browser!

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.)

Add/Edit Members Adding "members" (borrowers) to the library or changing information about a borrower can be started from the Koha home page.

Member management from home page If you happen to be at the home page when a potential borrower asks to be added to the library's membership, this works well. In most cases, however, you will get to member management from the circulation page, either through the pull-down "Members" menu at the top of the page, or by clicking on "Add" or "Edit" after doing a search for borrowers. No matter how you get there, the screen you will see is the same.

Member detail entry On this page, required information appears in bold type with an asterisk: the card number, the given (first) name, the surname (last name), the postal address, and the town. It is to your advantage, of course, to fill in the rest of the fields with as much information as possible. Many of the fields on this screen are designed to allow flexible data entry; the zip code, for example, may be called "postal code" in your country, or may not even be an important part of your addresses. Decide how you want to use the fields and then try to be consistent as you add new members or edit information about existing borrowers. A few of the fields on this page deserve some explanation. Card number If you set your "autoMemberNum" system preference to "1" (on), then card numbers will be calculated automatically and inserted into this field when new members are added. Category Be sure to choose the correct category for the member, since this may affect how loan periods and fines are calculated for this borrower. Notes (alternate contact) Use this field wisely; if you have extensive notes on how to contact others when you cannot contact the borrower, it will make your work easier when you have to hunt down a "missing" member. Expiry date If you leave this field blank when adding a new member, Koha can calculate the expiration date of the borrower's membership based on the "Enrollment Period" value you set for this borrower's category in the Borrower Categories parameter. Borrower message and Circulation note These two fields are most often used when adding extra information to an existing borrower's account. The "Borrower message" will appear on the OPAC screen when the borrower logs in; it is a handy way to communicate information to a borrower. The "Circulation note" is intend to communicate information to other staff members. Both the messages appear on the staff screen when a borrower presents their card at the circulation desk to check items out. FLAGS These three radio buttons can be used to set the status of the account. "Gone no address" means that mail to the borrower has been returned to the library and no new mailing address has yet been provided. "Lost" means the card (not the borrower!) has been reported lost. "Debarred" means the borrower has violated library rules and is not entitled to library services until the situation has been resolved. Sorting fields These are general-purpose fields that can be used to store any type of special information which might be used for retrieving the records of a special group of borrowers from the database. When you have filled in the fields, click on "Save." If any of the required fields have been left blank, you will receive an error message and be given the opportunity to add the missing information.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Paul Poulain If you have an LDAP server, Koha can use that to authenticate users. In the modules/C4 directory, you'll find the Auth_with_ldap.pm package. Open it with your text editor, modify it to fit your needs (LDAP server name and parameters), then : rename Auth.pm to Auth_ini.pm copy Auth_with_ldap.pm to Auth.pm It should work. Note that when you upgrade your Koha version, you have to manually copy your modified Auth_with_ldap.pm and overwrite the official Auth.pm once again. Don't forget to save the official Auth.pm somewhere; it can alway be useful. Posted by Kent Nasveschuk An anonymous bind to LDAP requires us to compare passwords by retrieving the password then comparing to what the user has supplied. If passwords stored in LDAP are hashed using different mechanisms, the burden of determining what mechanism is used is on the Koha application. I changed the code in Auth.pm a little so that bind() uses the person's DN and password. The burden of what password hash is used is on LDAP and not Koha. Between local in Auth.pm: ################################################## ### LOCAL ### Change the code below to match your own LDAP server. ################################################## # LDAP connexion parameters # LDAP server my $ldapserver = '172.16.0.24'; # Base DN for users my $name = "ou=users,dc=tow,dc=net"; # Bind uses the users full DN, if uid doesn't work try "cn" # my $binddn = "cn=$userid,$name"; my $binddn = "uid=$userid,$name"; my $db = Net::LDAP->new( $ldapserver ); # do bind my $res =$db->bind( dn =>$binddn, password =>$password); # check connexion, anything other code than LDAP_SUCCESS (0) # is a problem if($res->code != 0 ) { # auth refused warn "LDAP Auth failed server not responding or wrong user password combination"; return 0; # search user }else { my $userdnsearch = $db->search(base => "$name", filter =>"(cn=$userid)", ); my $userldapentry=$userdnsearch -> shift_entry; # build LDAP hash my %memberhash; my $x =$userldapentry->{asn}{attributes}; my $key; foreach my $k ( @$x) { foreach my $k2 (keys %$k) { if ($k2 eq 'type') { $key = $$k{$k2}; } else { my $a = @$k{$k2}; foreach my $k3 (@$a) { $memberhash{$key} .= $k3." "; } } } } # # BUILD %borrower to CREATE or MODIFY BORROWER # change $memberhash{'xxx'} to fit your ldap structure. # check twice that mandatory fields are correctly filled # my %borrower; $borrower{cardnumber} = $userid; $borrower{firstname} = $memberhash{givenName}; # MANDATORY FIELD $borrower{surname} = $memberhash{sn}; # MANDATORY FIELD $borrower{initials} = substr($borrower{firstname},0,1).substr($borrower{surname},0,1)." "; # MANDATORY FIELD $borrower{streetaddress} = $memberhash{homePostalAddress}." "; # MANDATORY FIELD $borrower{city} = $memberhash{l}." "; # MANDATORY FIELD $borrower{phone} = $memberhash{homePhone}." "; # MANDATORY FIELD $borrower{branchcode} = $memberhash{businessCategory}; # MANDATORY FIELD $borrower{emailaddress} = $memberhash{mail}; $borrower{categorycode} = $memberhash{employeeType}; ################################################## ### /LOCAL ### No change needed after this line (unless there's a bug ;-) ) ################################################## This works for passwords stored in LDAP that use MD5 or SMD5. I imagine it will work for other hashing mechanisms also. Posted by Bruno Marmol For testing the LDAP password, I needed to patch this code to not do an anonymous bind. I don't use the compare() function. I just do: my $res =$db->bind( "uid=$userid,$name",password => $password); # check connexion if($res->code) { # auth refused #warn "LDAP Auth: not binded"; return 0; }

Catalogue Searches in the Librarian Interface While working at the circulation desk, staff are likely to need to search the catalogue for bibliographic records. There are some differences between the information the librarian(s) will see and the information the public will see when searching the library catalogue. First, the librarian is presented with different search options than are available through the OPAC.

Librarian's catalogue search This screen is not accessed from the Circulation menu, but from the Catalogue menu. There are a few things that appear to be missing from this screen at first glance. The Advanced OPAC Search allows all of these searches, plus the ability to search on series title, format, and publication date range. What the OPAC search does not have, however, are the search fields at the bottom of this screen. These fields allow the librarian to search directly against the MARC record. The first box allows staff to choose an "and" or "or" (Boolean) search type for each line. The second box contains a pull-down list of all the MARC subfields which are not set as "ignored" in your default Biblio Framework; this list is also grouped according to the "tab" setting of each subfield. Choose which MARC subfield you wish to search from this list. The third box allows you to exclude a term by choosing "not" from the pull-down list. The fourth box allows you to control the search behavior; will the search look for the term contained somewhere in the subfield, at the beginning of the subfield, exactly matching the content of the subfield, etc. Finally, the fifth box is where you type in the search term. This ability to search directly against the MARC record is a powerful tool for the librarian. Notice that there is yet another area at the bottom of this screen that does not appear in the OPAC search screen. This area allows the librarian to: set the number of titles that will be displayed on each page of the search results; select if the results will be sorted by title, author, call number, publication year, or publisher; and choose either an ascending or descending sort. The display of the search results is also quite different from the OPAC search results. By default, Koha shows the MARC record. But a more useful display is either the "Complete" or "Normal" display, which can be accessed by clicking on the appropriate tab at the top of the display box.

Librarian's "Complete" search results Note that other tabs across the top of the display area allow the librarian to jump directly to some other tasks, such as editing or deleting an item record attached to this bibliographic record (if the logged-in user has permission to edit catalogue records), adding the book to a virtual shelf, or placing a request (reserve) on the book. Note also that there is more information on this screen than on the OPAC about the status of individual copies of this book. First, all copies are displayed, regardless of their current status, including lost and long overdue copies. Also the card number of the current borrower of a copy is given. This card number is a live link; clicking on it will display detailed information about the borrower. One other live link in the "Items" list is the barcode of each copy. Clicking on the barcode will display very detailed information about the copy.

Librarian's item details display Most of this information is self-explanatory. Note that there are again some live links: the current borrower's card number (to see borrower details); the "Accession Date," which will lead to a display of information about the order history of the copy (from the Acquisitions module); and the "Total Issues." This last link produces information about the issuing history of this copy.

Item Issue History This screen basically keeps track of the current and the "permanent" locations of the item, the number of times it has been issued at each branch, and the date and time when it was last scanned by a librarian.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.)

Cataloging and Acquisitions The function of a library catalogue is to retain descriptions of the items held by the library in such a way that the descriptions can be accessed and used effectively whenever an item needs to be retrieved from the collection. The function of cataloging is to build those descriptions and store them in a logical database (i.e. the catalogue) in such a way that knowing one part of the description allows the catalogue user to retrieve the entire description of the item. This chapter describes the process of maintaining a Koha catalogue, including the process of tracking the actual acquisition of library items. It does not provide general cataloging rules -- for those, you should consult one or more of the many cataloging web pages available on the Internet (often maintained by the "central" or "national" library of a country). This chapter also does not describe the process of setting up "biblio frameworks" -- see Chapter One for that information. This chapter simply tells you how to use Koha for recording information about items as you order them, and then tells you how to place MARC records describing those items into your Koha catalogue.

Building and Receiving Orders If you use Koha's Acquisitions feature, part of the bibliographic record can be added to the catalogue as part of the process of ordering an item. The primary purpose of the Acquisitions feature, however, is accounting for your orders.

Suppliers The first step in using the Acquisitions module is describing your suppliers and adding them to your list of vendors. This is actually done as part of the process of placing your first order with the supplier. Begin by going to the "Start, receive, modify order" box on the Acquisitions home screen and either search for the supplier by name (if you think they might already be in your vendor list) or leave the box blank and click on "OK."

Acquisitions Home Screen Notice that this screen displays any budget and currency information which was entered as part of setting up Koha for your library. The budget numbers will be modified as you place and receive orders to reflect any amounts you have spent or committed. When you click on "OK" without entering the name of a supplier in the search box, you will see a screen listing all of the suppliers in your vendor list -- which will be empty the first time you use Acquisitions.

Supplier List (First Use) Click on "Add supplier" and you get a screen allowing you to enter the details about this vendor:

Adding a Supplier When you click on "save" after entering the supplier information, you will be returned to the supplier list, this time with your new supplier available for selection. This supplier, along with all of the other suppliers in your vendor list, will also appear from now on whenever you search for a supplier without entering a search term.

Supplier List Click on the "Order" icon (mailing envelope) to proceed to the next step in the process of placing an order.

Shopping Baskets Once you have added the vendor to your files, the next step in building a new order is creating a shopping basket to hold the order. This process begins by adding an order line that gathers information about the item you wish to order, either by searching for a matching bibliographic record already in your catalogue, looking at patron suggestions, or creating a new bibliographic record.

Creating a shopping basket The "search on existing books" looks for your search term in the titles on the items in your catalogue. If you do not find a match for the item you wish to order, you can create a new bibliographic record for it. (See the instructions for acquiring or creating MARC records later in this chapter.) Or you can gather information from suggestions that have been accepted from patrons to start the process of building a bibliographic record. As you can see, regardless of how you go about it, the goal is to describe each item in an order using information from a bibliographic record in your catalogue. Let's look at using an existing record first, then look at the process of managing suggestions. If you search for a word (or words) from an existing title in your catalogue, you will see a list of search results to choose from.

Searching for matching record If you then click on the title of the matching item, a new shopping basket will be created, this first item will be added to it, and you will be returned to a screen for adding more information about this item order.

Item order details On this screen, the "catalogue details" are filled in using the information from the bibliographic record, and you now need to add the "accounting details." In particular, you need to specify the number of copies you wish to order, the fund from which the money is to be taken (using a pull-down list of funds you already defined in your Koha parameters) the replacement cost and the estimated (budget) cost. All the other calculations can be done based on information from your Koha parameters, so when you click on "OK," you will see something like this:

New order Note that the "managed by" information is not displayed on this screen, but is automatically defined in the shopping basket by the login name when the basket was created. In the example above, "Basket 1" will be managed by "kohaadmin."

Suggestions The Koha OPAC allows your library users to submit suggestions for library purchases. These suggestions are managed during the acquisitions process. When suggestions are being held by Koha for management by the librarians, a note on the acquisitions home screen will inform you:

Suggestions note Clicking on the "manage" button brings you to the list of suggestions currently awaiting action.

Suggestions list The pull-down menu above the "Change status" button lets you choose to either "accept" or "reject" this suggestion. (Once the status is changed, the new status is reported back to the OPAC user who made the suggestion.) If you choose to accept the suggestion, make sure you record the suggestion information before you change the status: the information will disappear once you have changed the status. Use the information to find or make a bibliographic record and proceed as above to add the item to a shopping basket.

Submitting an order When you have added as many items as you want to a shopping basket, you can submit the order. First you will need to display the shopping basket details (as if you were going to add more items to the basket) and then click on "Close" in the Basket Info window. This will return you to the supplier details screen, now showing that the basket has been closed.

Closed shopping basket If you now click on the "View" button, you see a different shopping basket detail screen (in this case, with only one item in the basket):

Basket ready to order Clicking on the "[order]" link at the top of the Fund column deducts the estimated cost of the order from the amount available in the fund(s) listed. The new available total will be displayed the next time you open the Acquisitions main page.

Receiving an order As items in an order arrive from the vendor, you need to "receive" them into your Koha database. This process starts exactly the same way you start the process of building an order, only now you click on the "Receive" icon (an in-box) instead of the "Order" icon.

Receiving an order This displays a screen for gathering some basic information about the shipment you have just received, namely the invoice number, any taxes, and any freight charges.

Order details Click on "save" to store this basic information about the shipment and proceed to the screen for searching your order lists for matching items:

Search orders The search should (of course) find a matching line in a saved order and display it, allowing you to enter details about this item from the invoice.

Receiving items In our example, we are going to assume we have received both copies that were ordered, but we will add them individually, so that we can assign one item to the MAIN library, and the other to a branch, each copy with it's own unique barcode. This adds the items immediately to the database as soon as you click on the "save" button. Now your order receipt summary displays the total costs, which should match the invoice total if you have entered everything correctly.

Receipt summary Only the actual cost of the items will be deducted from your book funds. Koha assumes that other charges (freight, taxes) come from other funds elsewhere in your budget.

Acquiring MARC Bibliographic Records While some cataloger somewhere obviously must create a MARC record for an item that has never been cataloged before, most cataloging is done by modifying MARC records that already exist; very little cataloging is "original" cataloging. Catalogers (much like open source developers!) share their work, so others can build on and improve what they have done. If you are using MARC, adding records to your database usually begins, then, with acquiring pre-existing MARC records. Importing good MARC records is very dependent on defining a good default Biblio Framework through the Parameters page. MARC tags that are "ignored" in the default Biblio Framework will not be imported into Koha when acquiring MARC records through Z39.50 or the upload of a file into the MARC reservoir. Spend extra time making sure that you have a well-defined default Biblio Framework, or consider using the koha/intranet/scripts/misc/migration_tools/bulkmarcimport.pl script to import files of MARC records directly into your catalogue.

The Z39.50 Search Z39.50 is an international standard computer protocol for exchanging data, including bibliographic records. To be precise, "Z39.50" is actually the standard identified as ISO 23950 or ANSI/NISO Z39.50. The standard specifies a client/server-based protocol for searching and retrieving information (like MARC records) from remote databases. You can find more information from the Library of Congress' Z39.50 home page, http://www.loc.gov/z3950/agency/. If you have chosen to use Koha with MARC support turned on, Koha includes a Z39.50 client for retrieving MARC records from libraries which maintain a Z39.50 server. The Koha code currently requires that the Event Perl module be installed on the Koha server; since the Event module will not work on Windows or Mac OS X, Koha's Z39.50 search feature is not available when Koha is installed on either of these operating systems. The next version of Koha should correct this deficiency, as it will incorporate next-generation Z39.50 technology. For now, however, the following instructions only apply to Koha installations on Linux/Unix systems. You start the Z39.50 search process by choosing :"Add biblio" from the "Catalogue" link. This is the first step in any cataloguing chore.

Add Biblio first screen This screen provides you with an opportunity to search your existing catalogue records and any records in your MARC reservoir before you add a new record. The purpose of this initial search is to avoid instances of duplicate records. For example, if you wanted to catalogue a book entitled Spy Catcher, you would enter that title in the "Title" search field and might get a result like this:

Add Biblio search result If nothing in the results screen matches the item you want to catalogue, you can click on the "Add New Biblio" button (and choose a Biblio Framework from the pull-down menu) to proceed to the next step. Likewise, if you are sure the item you want to add to the catalogue does not exist in either your current catalogue or your MARC reservoir, you can skip the search step and click on the "Create Empty Biblio" button on the first Add Biblio screen. Either way, you now come to the cataloging screen for adding a MARC record:

Add Biblio cataloging screen The appearance of this screen is controlled by the Biblio Frameworks that were set up when you defined your Koha parameters. The MARC record may be subdivided across as many as ten different screens, which can be accessed by clicking on the tabs (numbered beginning with "0") along the left side of the page. Above these tabs are two buttons: "Add biblio" (used to add the record to the catalogue when you have finished entering information) and "z3950 search." This second button is the one that we are now going to explain. The Z39.50 client will search for items by either ISBN, author, or title. An ISBN search will, of course, return the most relevant search results, but the other search methods are provided for items that do not have an ISBN. Let us assume that you now have an new book you want to catalogue -- Donna Tartt's The Little Friend -- and you have already searched your catalogue and come to the screen above for adding a new MARC bibliographic record. To use Z39.50 to search for a record from other libraries, insert the ISBN in the ISBN field and click on the "z3950 search" button:

Z39.50 Searching Notice that the ISBN is entered without any hyphens. Clicking on the "z3950 search" button opens a pop-up window that reports on the progress of the search, beginning by reporting "Still ?? requests to go." As results are found, the "??" will be replaced by the number of Z39.50 servers remaining to be searched, and finally a list of all the retrieved results will be displayed. There are several factors that can make the Z39.50 search fail at this point. First, you must have your browser set to allow pop-up windows from your Koha server. The window is actually opened to begin the search by a JavaScript, so your browser should also have JavaScript enabled. Finally, if you keep getting the "Still ?? requests to go" message over and over, your system administrator probably has not started the Z39.50 daemon using the koha/intranet/scripts/z3950daemon/z3950-daemon-launch.sh script. (If you are using a RedHat operating system and have problems starting the daemon, see the "User comments" at the end of this section.) Once Koha has searched through the list of Z39.50 servers that were setup in your Koha parameters, the pop-up window will display the search results.

Z39.50 Search Results At this point, all of the retrieved records have been added to your MARC reservoir. You can now choose from the list and click on the "Import this biblio" link next to your choice to automatically use that record to fill in the MARC values on your cataloging screen.

Z39.50 Imported Biblio After editing the MARC bibliographic record to include your local information (such as the Koha Itemtype in our example) and making any other changes, click on the "Add biblio" button to save the MARC record and proceed to entering the item information.

Importing MARC record files There are two ways to import MARC record (ISO2709) files into your Koha catalogue. One is to upload them into the MARC reservoir and draw them one-by-one from the reservoir into the regular catalogue. This function is accessed through the Parameters page, and is therefore explained in Chapter 1, Section 4.2. The second way involves running the bulkmarcimport.pl script from a terminal command line, and is therefore harder to use. This second method has the advantage, however, of importing the entire MARC record from the file, while the MARC reservoir upload will only import the MARC tags that are not ignored in your default Biblio Framework. Since this may be important at times, we will look briefly at bulkmarcimport.pl. First of all, bulkmarcimport.pl is an "extra script," and not part of the "normal" Koha code. It is really intended for special circumstances, but Koha users have found that it can be modified to enable routine uploading of batches of MARC records prepared outside of Koha. In any case, the user must take steps to pass certain information to the script so it can find the rest of the Koha code, particularly the Koha Perl modules. If this is not done, you will get a Can't locate C4/Context.pm in @INC error message, indicating that Perl cannot find the path to your Koha modules in its special @INC variable. There are two ways to tell Perl how to find the Koha modules: you can either modify the @INC variable in the bulkmarcimport.pl script, or you can set the PERL5LIB and KOHA_CONF environment variables before you run bulkmarcimport.pl. To modify the @INC variable from within the script, add this line to the list of "use" statements at the beginning of the script:use lib "/path/to/koha/intranet/modules"; Change /path/to/ to whatever is the actual path to your Koha files. The method for setting the PERL5LIB and KOHA_CONF environment variables will depend on the shell you are using in your terminal. If you are using bash or a Bourne-style shell, do: export KOHA_CONF=/path/to/koha.conf export PERL5LIB=/path/to/koha/intranet/modules For C-style shells, do: setenv KOHA_CONF /path/to/koha.conf setenv PERL5LIB /path/to/koha/intranet/modules Or if you are using Windows, do: set KOHA_CONF=c:\path\to\koha.conf set PERL5LIB=c:\path\to\koha/intranet/modules Once you have set the variables, you can run the script. Remember, though, that these special environment variable settings will be lost when you close the shell. If you are going to use bulkmarcimport.pl frequently, it is best to add the "use lib" line to the script itself. You might still get an error message like Can't locate Time/HiRes.pm in @INC when you start the script. This is a Perl module that is not routinely installed, but can easily be installed by doing perl -MCPAN -e 'install "Time::HiRes"' in a terminal command line. The bulkmarcimport.pl script does not do any sophisticated data manipulation; it simply reads an ISO2709 file record by record, puts aside any item (holdings) information, imports the basic bibliographic information, and then adds the item information. If you need to do any manipulation of the ISO2709 records, this should either be done before running the script, or the process of modifying the records can be inserted into the script. If you invoke the bulkmarcimport.pl script without any options, you get a help message: [root@localhost migration_tools]# ./bulkmarcimport.pl small script to import an iso2709 file into Koha. parameters : h : this version/help screen file /path/to/file/to/dump : the file to dump v : verbose mode. 1 means "some infos", 2 means "MARC dumping" n : the number of the record to import. If missing, all the file is imported t : test mode : parses the file, saying what he would do, but doing nothing. c : the char encoding. At the moment, only MARC21 and UNIMARC supported. MARC21 by default. d : delete EVERYTHING related to biblio in koha-DB before import :tables : biblio, biblioitems, subjects, items additionalauthors, bibliosubtitles, marc_biblio, marc_subfield_table, marc_word, marc_blob_subfield IMPORTANT : don't use this script before you've entered and checked twice (or more) your MARC parameters tables. If you fail this, the import won't work correctly and you will get invalid datas. SAMPLE : ./bulkmarcimport.pl -file /home/paul/koha.dev/local/npl -n 1 Be very careful when using the -d option; the script will not warn you that you are about to delete your existing data, it will just do it. Here is another example of invoking bulkmarcimport.pl: ./bulkmarcimport.pl -d -c UNIMARC --file records.mrc In this example, we are deleting all of the old data and importing a file of records called records.mrc, which uses UNIMARC character encoding.

<anchor id="getrecords" />- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Amzari Abu Bakar With RedHat 4 Enterprise ES (update 2), you will have a problem when executing z3950-daemon-launch.sh. This message will appear: This account is currently not available. This happens because RedHat does not allow scripts to run under the www-data/apache user account. A solution is to change the user of the z3950-daemon-option file from www-data to root.

Adding, Editing, and Deleting Bibliographic Records One of the most important things a librarian does is manage the metadata describing the library's resources. Put more simply, it is essential that a library maintain good catalogue records describing the items held by the library, so they can be found and retreived as needed. This involves modifying records created by other librarians to match a specific library's needs, or sometimes creating new records. This section assumes that the reader is familiar with cataloging theory and practice, and describes only the mechanics of adding, editing, and deleting bibliographic records in Koha. If you need help with the general cataloging concepts found in this section, many schools offer cataloging courses, and some "quick start" guides can be found on the Internet. This section is divided into two subsections; the subsection that is relevant to your library depends upon whether or not you enabled MARC support in your Catalogue system preferences. It is a good, idea, however, to scan through both sections, to get a complete overview of cataloging in Koha.

MARC Adding a new MARC record to the Koha database involves the "Add biblio" function. While there are several ways to access this function, the easiest is directly from the Koha home page, by highlighting "Catalogue" and "Add biblio":

Accessing 'Add biblio' The process of adding a biblio record starts with a search of the catalog, either by ISBN or by title, to verify that there is not already a catalog record for the item. If, however, you are certain that the item has never been cataloged before, you can bypass the search by clicking on the "Create empty biblio" button. (Be sure you choose the biblio framework within which you want to work before creating the empty biblio.)

Starting the 'Add biblio' process If you do a search first, you may find records that match your search term. If so, you must decide if one of these records is one you want to use, or do you need to create a new record. Note that the search looks not only in your active catalogue, but also in the reservoir of any other catalogue records you may have accumulated, perhaps from Z39.50 searches.

Cataloging Search If you decide to use an existing record, you can either edit the record to add new information, duplicate the record to create a new record based on the old record, or add an entirely new record to the catalogue. This decision will determine whether you click on "Edit," "Duplicate," or "Add New Biblio." (And again, be sure you choose a biblio framework from the pull-down menu next to the "Add New Biblio" button.) Regardless of what you choose, you finally arrive at the screen for entering or editing bibliographic information.

Cataloging Screen If you are editing a record or working with a duplicate record, some of the fields on this page will already have data in them. If you are adding a new record, most fields will be blank, unless your Biblio Framework specifically has some controlled values built into it (as is the case with MARC tag 090 in the figure). The fields that you see, where you see them, and controlled values in fields are all determined entirely by the Biblio Framework(s) you set up in your Parameters. If you find this display to be inconvenient, go back to Parameters and either edit your existing Biblio Framework or create a new one. There are some tag names that are followed by a plus sign ("+"); these tags may be repeated by clicking on the "+". (Currently, there is no mechanism for repeating subfields.) Other fields are followed by three dots ("..."); these fields can be filled in by referencing special scripts or authorities you may created. We will discuss the procedure for using these tools in the next section. When you have entered the values you want in all the fields you want (on all the tabs), click on "Add biblio" to save the general bibliographic record and proceed to the screen for adding item information. Since adding items is the same no matter whether or not you are using MARC records, we will look at that process after the section about adding bibliographic records to a non-MARC catalogue.

Authorities

Essential Fields

Non-MARC

Biblio Data

Group Data

Adding, Editing, and Deleting Copies (Items) -- to be completed

MARC

Non-MARC

Special Considerations for Serials (MARC) -- to be completed

Serials Information materials that are published in installments over a period of time are commonly called "periodicals" or "serials." Management of serials is a challenge for any Integrated Library System. Librarians often expect the Serials Module of an ILS to do several tasks at the same time: display general (bibliographic) information about the publication; display information about which installments of the periodical are held by the library; allow the librarian to track missing and/or late issues; and allow the library to circulate issues to patrons, if the library's policy permits this. Koha's Serials functions can handle the first three of these tasks, although holdings information (the second task in the list) is not handled in the MARC record in Koha; instead, it is handled in a special table in the database. This is because the different flavors of MARC, especially MARC 21 and UNIMARC, handle holdings information for serials in very different ways. Since Koha is intended to work with any flavor of MARC, serials holdings data thus has to be stored outside of the MARC record. For the same reason, Koha cannot handle circulation of holdings as part of the Serials function. If your library intends to circulate issues of serials, you should plan to create very brief MARC records for each issue and attach holdings data to the record as you would for a book.

Setting Up the Serials Module

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Owen Leonard The N/[X,Y] formula for managing issues of serials is a little confusing, but maybe an example will help: Many serials are identified by a custom numbering formula like "Vol. 4, No. 7, Iss. 8" (Volume four, number 7, issue 8). The serials numbering formula calculator in Koha allows you to automate the updates of those values according to each serial's special formula. In this case, your Koha formula would look like this:Vol. {X}, No. {Y}, Iss. {Z} Each number in the formula is replaced by a variable. In the numbering calculation table you set the rules for how each number is incremented as each serial issue is acquired. Let's say in this example that your serial title releases 12 issues a year, that each 'number' collects 12 issues, and each 'Volume' collects 10 'Numbers.' It's easier if we start with the {Z} column:

Add 1 <-- Issue number increments by one once every 1 <-- Issue number increments by one each time an issue is published When more than 999999 <-- Issue number should not reset to zero, so enter a huge number here The loop is for instance 0 <-- Where are we in the current sequence? Since {Z} increments by one and does not reset, this value isn't needed. Set back to 0 <-- In this case we hope it doesn't ever get set back Last value 8 <-- The next issue should have this value

In the {Y} column:

Add 1 <-- Each 'Number' increments one at a time Every 12 <-- 'Number' increments by one every twelve issues When more than 10 <-- 'Number' resets every 120 issues (12 issues x 10) The loop is for instance 7 <-- Indicates that we're starting at 7 of 10 Set back to 1 <-- reset to 1 every 120 issues Last value 7 <-- The next issue should have this value for "No."

In the {X} column:

Add 1 <-- Volume is incremented by one Every 120 <-- Volume increments by one every 120 issues When more than 999999 <-- Volume number should not reset to zero The loop is for instance 0 <-- Volume doesn't reset, so this can be left 0 Set back to 0 <-- Shouldn't ever be reset, we think Last value 4 <-- The volume numbering should begin with 4

With those values entered, the numbering system for each new issue should look like this (if I got the math right): Vol. 4, No. 7, Iss. 8 Vol. 4, No. 7, Iss. 9 Vol. 4, No. 7, Iss. 10 Vol. 4, No. 7, Iss. 11 Vol. 4, No. 8, Iss. 12 ... Vol. 4, No. 10, Iss. 36 Vol. 5, No. 1, Iss. 37 Posted by Henri-Damien LAURENT To see your serials in your catalogue you MUST : create or choose BOTH the supplier AND the general biblio of your serial; add a subscription named with this serial and include both supplier and notice information.... And add a formula, subscription date, frequency and subscription length...

Managing Serials -- to be completed

Reports -- to be completed What are reports

Pre-Defined Reports

Custom Reports

Routine Maintenance Once you have Koha installed and working, the system administrator's job is just beginning. Now come the daily tasks involved with keeping Koha "healthy": backing up data, restoring data if the system crashes, troubleshooting problems, etc.

Backups and Restoring This section is a copy of a separate document by Joshua Ferraro, jmf at kados dor org, written 2004-12-13 and available at http://www.kohadocs.org/Backups_and_Restoring.html.

Introduction Understanding how to properly backup and restore your Koha installation is a critical step in administering Koha successfully. Not only are these skills needed in an emergency, such as a hard drive failure on your primary production machine, but they are also useful for when you update, upgrade, or anytime you plan to custom modify either the filesystem or the database. There are three main components of Koha that must be considered when backing up and restoring: the database, the Koha filesystem, and the operating system customizations for the system. This document describes every step necessary for backing up and restoring both the database and the filesystem and points out some important considerations when backing up the operating system customizations -- these customizations often vary widely from system to system.

Backing up and Restoring the Koha Database

Backups There are many ways to backup MySQL databases, or parts of databases. After reading this section I highly recommend reading the MySQL manual sections that discuss backing up and restoring data. You can find them online at http://dev.mysql.com/doc/mysql/en/index.html. Perhaps the best way to backup your Koha database manually is the mysqldump application. To backup the whole database you can invoke it thusly: [root@frodo]# mysqldump --add-drop-table -uroot -pyour password Koha > 2004_11_30_koha.sql Notice that this naming convention uses the date, which makes it easy to organize a number of backups in a directory without being confused about which backup corresponds to which date. It's also clear that it's an SQL backup. Choose your naming conventions wisely and you'll thank yourself when you run into trouble. Also notice the option. This specifies that when you restore the data you will not append the data to existing data; additionally, if tables in your backup do not exist in the database they will be created. If you plan to work on a specific table and you'd like to back up just that table you can use mysqldump to do that as well. Suppose you're working on the issues table. You can back it up thusly:[root@frodo]# mysqldump --add-drop-table -uroot -pyour password Koha.issues > 2004_11_30_koha.issues.sql For more information on backups using the mysqldump utility please see the MySQL manual section 8.8: The mysqldump Database Backup Program. For more ways to backup your database, the MySQL manual is your best reference. Now you can use the gzip program to compress the sql file and reduce it's overall size for easier transport: [root@frodo]# gzip 2004_11_30_koha.sql

Restoration To unzip your file (in case you need to restore your database) you simply type:[root@frodo]# gzip -d filename.tgz An sql file can be used to restore data using the MySQL command-line tool. Here's an example of how to restore the Koha database using an sql file called koha.sql:[root@frodo]# mysql -uroot -pyour password Koha < koha.sql To restore a single table such as issues from a file called koha.issues.sql you would type:[root@frodo]# mysql -uroot -pyour password Koha.issues < koha.issues.sql

Role of Replication as Backup In addition to being useful in load balancing, replication can serve as a realtime backup for your Koha system. You will need to manually promote a slave to serve as master, and you will likely need to adjust your local configurations depending on how you have your systems setup, but having replication in place will probably ensure the fastest route to recovery from a complete system crash. See the replication section of the MySQL manual for more details.

Backing up the Koha Filesystem Even if you don't plan to use the latest CVS updates for your installation, it might be worth your time to centralize your Koha installation filesystem to ease the backup and restore process. For more info on how to achieve that see the Updating Koha section of the Koha documentation. To backup the Koha installation directory tree you need to ensure that all your Koha files are being considered. Most of them are located by default in /usr/local/koha. The koha-httpd.conf and the koha.conf files are located in the /etc/ directory.

Automating the Filesystem Backup Here's a short Perl script that I run with cron every evening. It backs up the filesystem using tar and gzip. You'll need to change some of the Configurable Variables for the script to work in your environment. Other than that, it's pretty much ready to go -- setup cron to run it nightly.#!/usr/bin/perl -w #This script assumes that you have set up a CVS repository #that is symlinked to your installation directories. For #info on setting that up see the Koha manual "Updating Koha" #Configurable Variables my $koha_base = "/build/websites/openils.com/koha"; #location of Koha cvs repo my $bak_loc = "/build/backups"; #where to put backups my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $year += "1900"; my $date = "$year-$mon-$mday"; #Backup the filesystem print "Backing up the filesystem\n"; print "Please wait ..."; `rm -rf $koha_base.bak`; #remove the previous backup `cp $koha_base $koha_base.bak`; #make a new backup `tar -cvzf $bak_loc/$date-kohafilesystem.tgz $koha_base.bak`; #targzip it

Backing up the Local Operating System Configuration It's best to write a script to perform all the local operating system configurations as you would manually perform them to ensure that in the event of an emergency, you can simply run the script to set everything the way you had it before. The list of possible custom configuration files for your system is unlimited, so I can just list a few common examples that you might want to consider including as part of your regular backup scheme: httpd.conf my.cnf any custom cron jobs related to Koha

Storing your Backup Offsite Using scp You may want to keep a copy of your database, filesystem and operating system customizations on your production server to ease the process of restoring should the need arise. However, what if your hard drive on that machine crashes? It's a very good idea to store your backups on a different machine (or two or three) and it's probably a good ideal to store them in a different building too. Perhaps the best way to avoid the problems inherent in physical backup medium such as a tape (that you may never really be sure is going to work anyway) is to use ssh and in particular scp as a part of your backup process. Why mess with tapes when you can securely copy a file from one system to another? You can invoke scp thusly:[root@frodo]# scp koha.bak jmf@sam.openils.com:/build/backups/ The : signifies that this is a network address and also allows a specific directory to be specified on the receiving machine -- in this case, sam.openils.com has a /build/backups directory where I store backups.

Troubleshooting -- to be completed

Getting Help Obviously the best place to look for help is the Koha documentation, most of which is stored on kohadocs.org. There is also a lot of good information on the Koha wiki, at koha.org/wiki. If you don't find anything helpful in these locations, then you should turn to the Koha mailing lists: access http://www.koha.org/community/mailing-lists.html to see what is available. The best of these lists for most problem-solving is the general Koha list, which you can join by filling out the form on the mailing-lists page. If you turn to the lists for help, always remember to include some basic information: which version of Koha what operating system information about relevant parameters settings -- for example, if you are having a cataloging problem, is marc "on" or "off" any portion of your error logs (usually in /usr/local/koha/log) that seems relevant Remember that Koha is an open community. You should always share your problems and solutions with everyone on the mailing list, no matter how trivial (or embarrassing) you may think the problem to be. If you are completely lost, or want to make some changes to Koha that are beyond your ability, remember that there are some companies that offer Koha service. A list of such companies is kept at http://www.koha.org/support/pay.html.

Koha Database Structure Koha currently stores all data in a MySQL database called "Koha." The Koha code expects the MySQL password hashing used in versions of MySQL before 4.1; if you are using MySQL 4.1, you should run your mysql daemon with the "--old-passwords" option. (Note that you may not need to do this if you are using Apache 2.0 or later.) MySQL 5.0 and later will not currently work with Koha because of a conflict between MySQL reserved words and Koha column names. If the use of a table or column is not apparent from its name, and you have a basic knowledge of Perl, you can use grep to search for the name in the Koha code. For example, if you want to know how the table sessions is used, try: [koha@localhost ~]$ grep -R 'sessions' /usr/local/koha/intranet/ /usr/local/koha/intranet/modules/C4/Auth.pm: "SELECT userid,ip,lasttime FROM sessions WHERE sessionid=?", /usr/local/koha/intranet/modules/C4/Auth.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=?", undef, $sessionID); /usr/local/koha/intranet/modules/C4/Auth.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=?", undef, $sessionID); /usr/local/koha/intranet/modules/C4/Auth.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=?", undef, $sessionID); /usr/local/koha/intranet/modules/C4/Auth.pm: $dbh->do("UPDATE sessions SET lasttime=? WHERE sessionID=?", /usr/local/koha/intranet/modules/C4/Auth.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=? AND userid=?", /usr/local/koha/intranet/modules/C4/Auth.pm: $dbh->do("INSERT INTO sessions (sessionID, userid, ip,lasttime) VALUES (?, ?, ?, ?)", /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: "SELECT userid,ip,lasttime FROM sessions WHERE sessionid=?", /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=?", undef, $sessionID); /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=?", undef, $sessionID); /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=?", undef, $sessionID); /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: $dbh->do("UPDATE sessions SET lasttime=? WHERE sessionID=?", /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: $dbh->do("DELETE FROM sessions WHERE sessionID=? AND userid=?", /usr/local/koha/intranet/modules/C4/Auth_with_ldap.pm: $dbh->do("INSERT INTO sessions (sessionID, userid, ip,lasttime) VALUES (?, ?, ?, ?)", /usr/local/koha/intranet/scripts/updater/updatedatabase: sessions => "( sessionID varchar(255) NOT NULL default '', /usr/local/koha/intranet/cgi-bin/logout.pl:my $sessions; /usr/local/koha/intranet/cgi-bin/logout.pl:open (S, "/tmp/sessions"); /usr/local/koha/intranet/cgi-bin/logout.pl: $sessions->{$sid}->{'userid'}=$u; /usr/local/koha/intranet/cgi-bin/logout.pl: $sessions->{$sid}->{'lasttime'}=$lasttime; /usr/local/koha/intranet/cgi-bin/logout.pl:open (S, ">/tmp/sessions"); /usr/local/koha/intranet/cgi-bin/logout.pl:foreach (keys %$sessions) { /usr/local/koha/intranet/cgi-bin/logout.pl: my $userid=$sessions->{$_}->{'userid'}; /usr/local/koha/intranet/cgi-bin/logout.pl: my $lasttime=$sessions->{$_}->{'lasttime'}; /usr/local/koha/intranet/cgi-bin/logout.pl:my $sth=$dbh->prepare("select userid,ip from sessions where sessionID=?"); /usr/local/koha/intranet/cgi-bin/logout.pl:$sth=$dbh->prepare("delete from sessions where sessionID=?"); If you want to reduce the amount of information returned, you can limit grep to looking in /usr/local/koha/intranet/modules/C4: the most useful information is likely to be found in these Koha modules. Most of the modules also have documentation that can be accessed using perldoc: [koha@localhost ~]$ perldoc /usr/local/koha/intranet/modules/C4/Auth.pm NAME C4::Auth - Authenticates Koha users SYNOPSIS use CGI; use C4::Auth; my $query = new CGI; my ($template, $borrowernumber, $cookie) = get_template_and_user({template_name => "opac-main.tmpl", query => $query, type => "opac", authnotrequired => 1, flagsrequired => {borrow => 1}, }); print $query->header( -type => guesstype($template->output), -cookie => $cookie ), $template->output; DESCRIPTION The main function of this module is to provide authentification. [snip] checkauth ($userid, $cookie, $sessionID) = &checkauth($query, $noauth, $flagsrequired, $type); Verifies that the user is authorized to run this script. If the user is authorized, a (userid, cookie, session-id, flags) quadruple is returned. If the user is not authorized but does not have the required privilege (see $flagsrequired below), it displays an error page and exits. Otherwise, it displays the login page and exits. You should now have a pretty good idea of how the sessions table is used by Koha. Here is the database structure of Koha 2.2.4: SHOW TABLES; +-------------------------+ | Tables_in_Koha | +-------------------------+ | accountlines | | accountoffsets | | additionalauthors | | aqbasket | | aqbookfund | | aqbooksellers | | aqbudget | | aqorderbreakdown | | aqorderdelivery | | aqorders | | auth_header | | auth_subfield_structure | | auth_subfield_table | | auth_tag_structure | | auth_types | | auth_word | | authorised_values | | biblio | | biblio_framework | | biblioanalysis | | biblioitems | | bibliosubject | | bibliosubtitle | | bibliothesaurus | | bookshelf | | borexp | | borrowers | | branchcategories | | branches | | branchrelations | | branchtransfers | | catalogueentry | | categories | | currency | | deletedbiblio | | deletedbiblioitems | | deletedborrowers | | deleteditems | | ethnicity | | issues | | issuingrules | | items | | itemsprices | | itemtypes | | marc_biblio | | marc_blob_subfield | | marc_breeding | | marc_subfield_structure | | marc_subfield_table | | marc_tag_structure | | marc_word | | marcrecorddone | | printers | | reserveconstraints | | reserves | | serial | | sessionqueries | | sessions | | shelfcontents | | statistics | | stopwords | | subscription | | subscriptionhistory | | suggestions | | systempreferences | | uploadedmarc | | userflags | | users | | websites | | z3950queue | | z3950results | | z3950servers | +-------------------------+ 72 rows in set These tables can be divided into four groups: tables holding descriptive data; tables holding borrower data; tables holding bibliographic data; and tables holding transaction data

Translating Koha Because Koha is open source, it can be translated to most languages without much trouble. The tools and instructions you need are found in the intranet/scripts/misc/translator directory of your Koha installation. The instructions are contained in the file translator_doc.txt, which is reproduced here: TRANSLATION TOOL, V3.0: ====================== This translation tool should greatly help Koha translators. It's composed of 2 scripts (with a number of associated perl module files): 1. xgettext.pl, that extracts the texts in a template, and which is called by the script; and 2. tmpl_process3.tmpl, which can do 3 things: a. create a file with all the "translatable strings" in all files in a directory (& its subdirectories), b. update an existing translation file, and c. rebuild translated templates from English & translation file. Call tmpl_process3.pl --help to get a more detailed explanation. Some additional explanations are also available by calling perldoc tmpl_process3.pl. HOW TO TRANSLATE Koha: ===================== 1. Create your translation file (assuming your current directory is this directory, i.e., misc/translator): ./tmpl_process3.pl create -i ../../koha-tmpl/opac-tmpl/default/en/ -s po/css_opac_fr_FR.po -r (In the above example, ../../koha-tmpl/opac-tmpl/default/en/ contains the English templates in the "default" theme, and po/css_opac_fr_FR.po is where you want the generated PO file to appear. The use of relative paths for the English templates is recommended; it makes the resulting PO files slightly shorter and more usable in a team environment. Absolute paths are certainly fine, and might be better if there is only one translator for your language.) 2. Translate your css_opac_fr_FR.po file using a text editor or a PO file translation tool. 3. Create your translated templates: ./tmpl_process3.pl install -i ../../koha-tmpl/opac-tmpl/default/en/ -o /home/paul/koha.dev/koha/koha-tmpl/opac-tmpl/default/fr2/ -s po/css_opac_fr_FR.po -r (In the above example, /home/paul/koha.dev/koha/koha-tmpl/opac-tmpl/default /fr2/ is where you want your translated templates to be saved.) 4. Copy images/css files in your new directory (as they are NOT moved by tmpl_process3.pl install). If something changes in the English version: 1. Update your translation file: ./tmpl_process3.pl update -i ../../koha-tmpl/opac-tmpl/default/en/ -s po/css_opac_fr_FR.po -r 2. Translate your newly updated css_opac_fr_FR.po file. Look for strings marked as "fuzzy" and strings that are not translated. 3. Create your translated templates: ./tmpl_process3.pl install -i ../../koha-tmpl/opac-tmpl/default/en/ -o /home/paul/koha.dev/koha/koha-tmpl/opac-tmpl/default/fr2/ -s po/css_opac_fr_FR.po -r 4. Copy new images/css files in your new directory if needed WEAKNESSES ========== For a somewhat up-to-date list of weaknesses, please run perldoc xgettext.pl and perldoc tmpl_process3.pl and read the BUGS sections. COPYRIGHT ========= * Paul Poulain (paul.poulain _@_ free.fr) & Jerome Vizcaino (vizcainj _@_ esiee.fr) * Parts of V3.0 by Ambrose Li (acli _@_ ada.dhs.org) These instructions require some additional explanation for those who are not familiar with "PO files." A PO file is a translation tool used by the GNU gettext utilities. See http://www.gnu.org/software/gettext/manual/ for a detailed description of gettext, but you don't have to be a gettext expert to translate Koha. The tmpl_process3.pl script takes care of the difficult stuff for you. When you run the script with the option it extracts information from any set of Koha templates which you name (usually the default English templates) and creates a PO-format file with all of the terms you need to translate. The file will contain a list of entries that look something like this: #: ../../koha-tmpl/intranet-tmpl/default/en/help/admin/categorie.tmpl:11 msgid "\"C\" (Children) is a borrower category that has a \"guarantor\"" msgstr "" #: ../../koha-tmpl/intranet-tmpl/default/en/help/admin/categorie.tmpl:9 msgid "" "\"I\" can be used for institutional members, like other libraries that " "borrow from you, in which case Koha expects slightly different information " "about the institution;" msgstr "" All you need to do now is insert the translation of each msgid between the quotation marks of the corresponding msgstr. This can be done using any text editor, or is even easier if you use a PO editor like kbabel. When you are done translating everything, run tmpl_process3.pl again with the option and it will create all the Koha templates in the new language. If the default templates are changed, run tmpl_process3.pl with the option and check the resulting PO file for missing translations.

Special problems Some languages are not so simple to translate, because of character-encoding or direction problems. If you have successfully overcome such a problem, please post your experiences to one of the Koha mailing lists or send them to st.hedges AT gmail DOT com. They will be added to this section.

Bengali Posted by Parthasarathi Mukhopadhyay Finally I have done Koha localization (in Bengali language - an Indian regional language) for both the version Windows and Linux. The procedure I adopted is as follows: I copied npl directory under opac-template in a new folder npl_bengali. Then changed charset=ISO-8859-1 to charset=UTF-8 everywhere it (charset=ISO-8859-1) appeared in .INC file under /include directory. In the system parameter setup I then changed opac theme to npl_bengali (it appeared as an option automatically). Finally used an Unicode compliant virtual keyboard (Avro) to enter query, to enter cataloguing data and to change interface language. [ed. note: www.omicronlab.com/avrokeyboard/] It works nicely. I have also tested import and export of Koha data (bibliographic, members etc.) in MySQL directly and found it works correctly. I'm entering data in Linux server through Windows XP client because virtual keyboard is available in Windows version only. Possibly in future we'll overcome this limitation also. For more information, see Five Laws and Ten Comandments: The Open Road of Library Automation in India.

Turkish Posted by Tumer Garip Here is what we had to do to use Koha in utf-8, hoping that it helps in some of your discussions: We are using Koha since 2.2.0 now at 2.2.2b We use English for intranet and English-Turkish for opac The platform is Windows We changed the character set of the database to utf-8 with the iso-xxxx data in it. No problem for MySQL as you are moving up the ladder. No need to reload the data (10 min) Changed all the charset=iso-xxxx in the templates to read utf-8 and saved the files as utf-8 (15 min.) in a simple text editor. Character decode in biblio for MARC21 is very ambiguous for us because it is not very clear which character encoding it is changing from. All the MARC records we bulkimport are MARC-8 , iso2709 or ANSEL or whatever you want to call them. So we simply wrote a one to one character mapping of MARC-8 to utf-8 for our Turkish accented characters. Here it is:#Additional Turkish characters s/(\xf0)s/þ/gm; s/(\xf0)S/Þ/gm; s/(\xf0)c/ç/gm; s/(\xf0)C/Ç/gm; s/\xe7\x49/Ý/gm; s/(\xe6)G/Ð/gm; s/(\xe6)g/ð/gm; s/\xB8/ý/gm; s/\xB9/£/gm; s/(\xe8|\xc8)o/ö/gm ; s/(\xe8|\xc8)O/Ö/gm ; s/(\xe8|\xc8)u/ü/gm ; s/(\xe8|\xc8)U/Ü/gm ; s/\xc2\xb8/ý/gm; All the character codes are directly from LC's website about MARC21. Since we provided the actual characters rather than their codes we saved the Biblio.pm as utf8 to save time. (Half a day together with research) We have a full working Koha as utf8 supporting all characters and we keep doing the same thing every time we get an update. Translation of opac files through .po files do not work for us. As we see it, this po translator is simply a search and replace text engine. So it converts the string ' English English <somevariable> English.' to ' Turkish Turkish <somevariable> Turkish'. Which is useless as it should be 'Turkish <somevariable> Turkish Turkish'. So we sat down and translated the opac templates to proper Turkish. It is now easier for our people to follow the changes in cvs and implement the changes to templates rather than doing complete translations every time. The whole update up till now is taking less than half a day with one person doing it. We as Windows people do not have much experience with this po editor. But as far as I know it supports utf-8 so what's the hassle about these translations? As far as we understand it the official language of Koha is English and if someone is translating it to some other language it is their responsibility to find the resources to translate it in time to be implemented as an additional language. Even if this requires a complete rewrite of some templates. Finally we believe that Koha should start using utf-8 ASAP before the move to zebra to gain experience. If zebra is implemented with all this iso stuff we will have more problems with each translation requiring a different character set and sort order set and character mapping to set, etc. Koha is more powerful with more features, stability and performance and I believe people will be more happy to see improvement in these even if they have to spend a little bit more resource on their own translations.