https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712
Lari Taskula <lari.task...@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60150|0 |1 is obsolete| | --- Comment #25 from Lari Taskula <lari.task...@jns.fi> --- Created attachment 60261 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60261&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 watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/