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

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Tue Dec 27 17:19:55 CET 2016


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

--- Comment #9 from Lari Taskula <lari.taskula at jns.fi> ---
Created attachment 58450
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58450&action=edit
Bug 17712: Centralize availability-related checks

There are some problems to our current approach for "availability" which makes
it complicated to integrate with e.g. REST API.

Firstly, there has been no unified way of representing reasons for
unavailability. Previously, each implementation of availability calculation has
chosen its own way for describing the reasons. For example, CanItemBeReserved
string "ageRestricted" vs. CanBookBeIssued key "AGE_RESTRICTION" in a HASHref.

Secondly, some of the availability logic is contained outside centralized
methods like CanItemBeReserved which is missing checks e.g. for maxreserves
(checked instead in opac-reserve.pl) and patron fines. Perhaps this issue could
be fixed in another Bug, but I propose we squash it at the same time with this
Bug. Currently, because of this, we will not get reliable responses to
holdability from CanItemBeReserved alone.

This causes problems for API integration where we need to be able to describe
the reason in an uniform way and additionally provide information on what needs
to be done to fix the issue. Also, we do not want to duplicate all the external
checks from .pl files into our REST controllers.

Instead of modifying the old methods, I propose a new structure for the whole
availability-problem and let us deal with proper "status-codes" to easily
integrate availability & additional availability-related information into e.g.
REST API.

My proposal is an approach to centralize the availability-related checks and
have
them return uniform reasons to describe reasons for availability problems.

Ultimately, we could ask availability something like this:
my $holdability = Koha::Availability::Hold->biblio({
  biblio => $biblio,
  patron => $patron,
  to_branch => 'CPL',
})->in_opac;

...and $holdability->unavailabilities HASHref would contain Koha::Exceptions
possibily with additional parameters to let us know why this biblio is not
holdable in OPAC.

This patch adds all availability related logic with centralization in mind.
From
these individual methods we are able to construct full availability queries in
order to determine if something is actually available in some way and also
describe the problems with the help of Koha::Exceptions.

Since availability is a mixture of multiple different smaller checks from
multiple
categories like item, patron, issuing rules, etc, they can be categorized into
their own subclasses. This lets us centralize availability-related methods per
category into their own modules.

To test:
1. prove t/db_dependent/Koha/Availability/Checks/*

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


More information about the Koha-bugs mailing list