[Koha-bugs] [Bug 17712] New: Move availability calculation to the Koha namespace

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712

            Bug ID: 17712
           Summary: Move availability calculation to the Koha namespace
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Circulation
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: lari.taskula at jns.fi
        QA Contact: testopia at bugs.koha-community.org
                CC: gmcharlt at gmail.com, kyle.m.hall at gmail.com

Created attachment 57921
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=57921&action=edit
Diagram to proposal for new classes and their relations

Currently some availability-related calculations are scattered around in
different modules (which alone is not bad) but also in Perl-scripts, like
opac-reserve.pl that has some patron related checks, maxreserves and some
other.

With this problem I think it is confusing for someone to figure out how
availability is calculated. This also makes it difficult to implement something
new that needs to find out different levels of availabilities. An example of
"anything new" would be REST API, which needs to be able to tell different
availabilities (biblio/item holdability, checkout availability both anonymously
and with patron restrictions etc). As of now, if we simply ask
CanBookBeReserved in REST controller, we are completely ignoring patron
debarments and fines, and maxreserves system preference.

Another problem is that currently there is no unified way of reasoning
unavailability between holds and checkouts. There are strings from
CanItemBeReserved, then there are HASHrefs with additional parameters from
CanBookBeIssued, then some simple checks that may be simply 1 or 0, like
IsAvailableForItemLevelRequest. REST API should however return uniform error
codes. Also CanItemBeReserved has the problem that it returns the first reason
in case of unavailability, and not all of them, if there would be more. An
end-user would probably want to know all problems at once instead of fixing one
to only find out there is another.

My proposal is to move availability-related calculation and checks into Koha
namespace. I propose adding a class, Koha::Availability, that is able to
contain availability-related information. It would contain methods to easily
find out availability status and any reasons to unavailabilities. To represent
reasons for unavailability/additional messages/needs for confirmation, I
propose objects instead of strings or hashes. These objects could be
Koha::Exceptions. Availability calculation could be categorized into
Koha::Availability::Calculation's subclasses. Answers to item availability
could be located in Koha::Item::Availability::Hold and
Koha::Item::Availability::Checkout.

This setup would let us have an unified way for handling availability the same
way everywhere.

How would it work in practice? I will describe my idea with "ingredients" and
"recipes":

- "ingredient": anything availability-related sub-check or sub-calculation
(e.g. item withdrawn, reservesallowed in issuing rules, age restriction etc.)
that returns a Koha::Exception::* if it spots a problem. These could be located
in Koha::Availability::Calculation subclasses.

- "recipe": a set of ingredients that cooks an answer to question "is something
available in some way", for example:
** "Q: does an anonymous user see an item available in search result? -> A: no,
unavailability reason: Koha::Exceptions::Item::NotForLoan"
** "Q: is an item available for hold for this patron? -> A: yes, additional
note: Koha::Exceptions::Item::NotForLoan with parameter code => 'Ordered'" 
** "Q: is an item available for checkout for this patron by a librarian -> A:
possibly; librarian needs to confirm Koha::Exceptions::Patron::Debt, exception
includes field max_outstanding => 10.00, current_outstanding => 15.00"
These could be located in Koha::Item/Biblio::Availability::Hold/Checkout

The ingredient would contain all logic to spot a problem. The recipe would use
what ever ingredients it needs to, and decide if a problem is worth of
unavailability, additional note or perhaps ask a confirmation. This is somewhat
same as CanBookBeIssued, but the point is to move all calculations away from
the recipe so that we can re-use the same logic in another availability recipe.

Any thoughts on this idea and current availability in general?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.