Alex Sassmannshausen Table of Contents ───────────────── 1 ILL for brave souls .. 1.1 Impact on Koha .. 1.2 Installing the module .. 1.3 Architecture 1 ILL for brave souls ═════════════════════ The interlibrary loans module provides a general framework for managing interlibrary loans in different contexts. It has a very general idea of what is involved in managing interlibrary loan requests: • Requests should be placeable in Koha • Details of these requests should be kept in Koha • Users should be able to find out the status of their requests in Koha • A request's journey, from placement to return, should be trackable in Koha. The way the module implements this is by creating a database structure for storing requests and their status, and by providing a 'language' to describe ILL workflows and stages. We can then delegate to individual backends that make use of this language to actually satisfy the ILL journey. 1.1 Impact on Koha ────────────────── The interlibrary loans module is largely an isolated module: it operates on 2 tables (illrequests and illrequestattributes), and simply adds a few links to existing Koha pages. Outside of this, the module simply operates in its own template, script and module files. Specifically, we touch: • api/v1/swagger/paths.json to add an ILL REST API • /etc/koha-conf.xml to add some ILL configuration • circ-menu.inc to add a link to the ILL module • intranet-main.tt to add a link to the ILL module • usermenu.inc as above • opac-results & opac-results-grouped to add ILL recommendations The trivial nature of these changes to core Koha code should mean that the chance of regressions in Koha is minimal. The ILL module does add a new, substantial amount of code, and this code will need to be maintained into the future. Hopefully the extensive unit tests will automatically detect breakage as a result of core Koha code changes. 1.2 Installing the module ───────────────────────── Installing the ILL module consists of 2 phases: 1) install the module patch set — there should be at most trivial merge conflicts 2) install backends of choice. You can see what backends are currently available at: [https://wiki.koha-community.org/wiki/ILL_backends] You will need to install at least one backend for the module to work. If you just want to give it a spin I would suggest you use the Dummy backend for now. If you want to experiment in a specific context then feel free to install one of the other backends. Backends need to be installed in a specific folder: ┌──── │ │ cd $koha_code_dir/Koha/ │ mkdir Illbackends │ cd Illbackends │ git clone $uri_to_backend │ └──── Once this is done you should be able to enable the backend module, browse to the ILL interface (which should have appeared on intranet-main if you have sufficient privileges), and create a new request using one of the backends you installed. Some backends may well require additional configuration. There is currently no standardised way to handle this, so the backend of your choice may be able to help you with this. 1.3 Architecture ──────────────── The ILL module adds 2 new Koha objects: Illrequests and Illrequestattributes. The former stores information about requests that are needed by the module to provide a core Koha user experience. The latter is a key value data store that can be used in arbitrary ways by a given backend. Data in this store is always associated with a specific request and keyed on a 'name' for the value. A backend needs to provide 3 things: 1) a Base.pm file that implements core methods (see the Dummy backend for a comprehensive example). 2) an intranet templates directory that contains 1 template toolkit snippet file for each of the core methods 3) an OPAC templates directory as above The OPAC template directory only needs to provide snippets for those parts of the user journey that are available in the OPAC. The module provides extensibility & flexibility through 4 mechanisms (please see the dummy backend for an illustration of these): • status_graphs allow for a backend to add new methods to the core ILL methods • custom stages associated with each method (whether core or custom) allow for a virtually arbitrary expansion of methods to encompass a great variety of workflows. • custom 'status change' updates can trigger actions specific to a given backend, almost like hooks of code that run at pre-defined times (when a request changes from, e.g. NEW to PROCESSING) • optional capabilities, such as unmediated ILL are provided as part of the core module, but don't have to be implemented by a specific backend