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
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
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #4 from Lari Taskula <lari.taskula@jns.fi> --- (In reply to Marcel de Rooy from comment #2) 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. 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.