Hello Kohites! Andrew and I have just finished a second major revision of our proposed interlibrary loans module for Koha. The code and bug can be found at [https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317]. We believe the code has now reached the maturity it requires for wider engagement, and, more importantly, it's now reached the maturity that it should be easy to get it up and running relatively easily in your development environments. Unfortunately we cannot deploy the module using sandboxes because backends are implemented as separate code projects. And we would *love* your comments thoughts and concerns about the module if you are interested in ILL! The final comment on the bug contains basic documentation for the Module as a whole, and also some installation instructions. But for reference, I've attached the same document to this email too. Below you will find some further high-level background and a roadmap of what we would like to achieve. For now, if you're interested in this module: • have a look at the bug, and get involved in the discussion! • try to set up the module in your dev environment. It should work easily on dev boxes and dev installs that track master. • let us know if you face any issues! • start a conversation with us if you might be interested in creating a backend for your country's / organization's ILL workflows. Finally, if you don't have access to a development environment, but you would be interested in becoming involved in this project, get in touch and we might be able to provide you with access to a testing environment! Best regards, Alex Sassmannshausen PTFS Europe 1 High-level background ═══════════════════════ The ILLModule aims to provide a core framework against which different ILL workflows can be implemented within Koha. It achieves this by using 2 new tables as data store, and by using an extensible backend system to create 'connectors' to ILL providers. The data store consists of the illrequests and the illrequestattributes tables. The former is a traditional table that stores essential values associated with an ILL request. The later is a key/value store, linked to a row in the former. This store can be used to store arbitrary data provided by a backend. The backends implement highly customizable workflows for several core steps in the ILL management process. At the same time, each backend can extend the core steps (called defined as the `core_status_graph` in Koha/Illrequest.pm) with their own additional steps (defined as the `status_graph` in a backend's Base.pm). Each of these steps, both core and extensions, in turn can define any number of 'stages' required to complete each individual step. Each step has access to a template include file, which can dispatch on 'stage'. This is mirrored by each step having a sub in a backend's Base.pm, which once again can dispatch on 'stage'. The subs in Base.pm have access to the full data store provided by the ILLModule; similarly the template includes have full access to Koha template features, including access to custom JS blocks through which, for instance, external APIs can be called. The main aim of this Koha module was to provide a core that is comprehensive enough to store core data to only have to implement ILL once in Koha, whilst being extensible enough so that virtually any ILL workflow can be implemented against this core. We believe we have achieved this. I'd be very interested to hear from you if you believe you have a workflow that cannot be captured by this (obviously, third party tools that do not provide API access will be virtually impossible to seamlessly integrate into Koha). 2 Roadmap ═════════ The roadmap starts from the current release of code on the bugzilla issue. • Publication of mature beta level code (21 February 2017) ⁃ public testing ⁃ public discussion ⁃ dogfooding • Augment core functionality (~ June 2017) ⁃ add advanced configuration options for the core module ⁃ add a standard system for configuring backends ⁃ allow for an 'unmediated workflow' ⁃ finalise 'generic requests' workflow • Meet Koha QA standards (~ July 2017) • Add unit tests to core ILLModule • Ensure UI respects Koha standards • Ensure Core code passes qa scripts • Addition of Documentation ⁃ contributing a chapter to the Koha manual ⁃ ensure all pod information is correct and complete ⁃ ('writing your own backend' tutorial?) • Provide consistent error handling ⁃ standard means through which a backend can 'throw' an error. ⁃ replace uses of die with this standard route • Integration into Koha core in Koha 17.11