[Koha-bugs] [Bug 17712] 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

--- Comment #4 from Lari Taskula <lari.taskula at jns.fi> ---
(In reply to Marcel de Rooy from comment #2)
> Just in first glance, I would not choose for an Availablity object. We also
> need to define what we mean with "available" exactly: available for loan for
> instance?
Thanks for the comment Marcel! Indeed, availability needs a proper definition
to have a meaning. Also considering the perspective; Available for hold to
patron, by who? Patron themselves? A librarian? If a patron asks if they can
place a hold, they get an unavailability reason for having too much fines. If a
librarian asks the same for patron, they get the same reason but additionally
the information that it is possible to override it by confirmation.

> I would probably opt for Koha::Item->is_available methods and similar. Or
> perhaps is_available_for_loan, can_be_reserved etc. Same for Koha::Biblio.
> Shared code in this regard might perhaps go in Koha::Util::xxx ?
Just curious, how would you represent the answer to availability (what would
these return)? Initially I was considering the same solution, but the
complexity of availability eventually made me think of putting them it into own
classes.

I think that all types of availability answers should always be represented the
same, uniform way. It could be a HASHref like in CanBookBeIssued, but I would
prefer an object that contains the availability information (Koha::Availability
in my proposal) but doesn't define and care about the type of availability; it
exists to ensure that we always have the same operations on availability
information (to contain yes/maybe/no value to availability, to contain and
return additional notes, reasons to ask for confirmation and unavailabilities).

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