[Bug 17712] New: Move availability calculation to the Koha namespace
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@lists.koha-community.org Reporter: lari.taskula@jns.fi QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #1 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- I stumbled across item status also in bug 17624 in particular referring to the Availability line in the OPAC XSLT results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #2 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Lari Taskula from comment #0)
Any thoughts on this idea and current availability in general?
Fist, I very much welcome the idea. 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? 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 ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #57921|0 |1 is obsolete| | --- Comment #3 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 57923 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=57923&action=edit Diagram to proposal for new classes and their relations -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josef.moravec@gmail.com -- You are receiving this mail because: You are watching all bug changes.
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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |16826 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16826 [Bug 16826] REST API: Add API routes for getting item availability and holdability -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Lari Taskula from comment #4)
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).
Since you spent more time on this already, it might well be that I would also arrive at some unified structure for these responses :) Koha::Availability just seems (at 'first' glance) to be a too prominent place for such a structure (imho). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #6 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58446 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58446&action=edit Bug 17712: Add new Koha::Exceptions To describe problems or notes to availability, we will be using Koha::Exceptions. This patch adds many useful Koha::Exceptions that we can use for this purpose. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #7 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58447 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58447&action=edit Bug 17712: Koha::Availability, a base for availability information This patch adds a new class, Koha::Availability, which is designed to contain availability information for each type of availability in an uniform way. Because of this, Koha::Availability has no actual availability calculation logic, but simply methods to get and set availability information into the object. With such design, we can next create new classes Koha::Availability::Hold and Koha::Availability::Checkout and let them inherit Koha::Availability so that they are able to handle availaibility information in an uniform way. Koha::Availability::Hold Koha::Availability::Checkout | | \_________________________________/ | Koha::Availability Koha::Availability can represent four levels of availability statuses: 1. available 2. available, with an additional note 3. available, but requires confirmation 4. unavailable Additional notes, reasons for a need to confirm and reasons for unavailabilities are kept in a HASHref, where each value in my proposal is a Koha::Exceptions::*. This allows us to easily store any additional data directly into the reason. For example, if we want to check biblio availability for hold and find out it is not available, the HASHref for unavailabilities has a Koha::Exceptions::Patron::Debt that contains parameters "current_outstanding" and "max_outstanding" which lets us pick up the information easily later on without making new queries. To test: 1. Run t/Koha/Availability.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #8 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58449 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58449&action=edit Bug 17712: Add base for item and biblio availability This patch adds two new classes: - Koha::Biblio::Availability - Koha::Item::Availability These classes represent biblio- and item-level availabilities and the purpose of this patch is simply to provide constructors that validate given biblio/item and patron parameters. Hold / checkout / search view availabilities (the actual answers to availability) will be provided in the next patches. To test: 1. Run t/db_dependent/Koha/Item/Availability.t 2. Run t/db_dependent/Koha/Biblio/Availability.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #9 from Lari Taskula <lari.taskula@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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #10 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58451 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58451&action=edit Bug 17712: Item availability for hold Adds Koha::Item::Availability::Hold class for item hold availability. This patch adds item holdability queries in two contexts: 1. in_opac (perspective of patron themselves) 2. in_intranet (perspective of a librarian to patron) Returns a Koha::Item::Availability::Hold object, which contains all information on availability for hold in that context. This may include additional notes, reasons to ask for confirmation or reasons for unavailability. Example: To find out if patron can hold an item in OPAC, we will write: my $availability = Koha::Availability::Hold->item({ patron => $patron, item => $item, to_branch => $branchcode, # transfer allowed from holdingbranch to to_branch? })->in_opac; if ($availability->available) { # yes! } else { foreach my $reason (keys %{$availability->unavailabilities}) { # each reason for unavailability } foreach my $reason (keys %{$availability->confirmations}) { # each reason that requires confirmation } foreach my $reason (keys %{$availability->notes}) { # each additional note } } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #11 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58452 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58452&action=edit Bug 17712: Biblio availability for hold Usage: $holdability = Koha::Availability::Hold->biblio({ biblio => $biblio, patron => $patron, to_branch => "CPL", })->in_opac; if ($holdability->available) { # yup! # arrayref of Koha::Item::Availability::Hold -objects: # 1. all available items (items may contain confirmations / notes) my $item_availabilities = $holdability->item_availabilities; # 2. all unavailable items my $item_unavailabilities = $holdability->item_unavailabilites; } Returns a Koha::Biblio::Availability::Hold -object. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #12 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58453 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58453&action=edit Bug 17712: Item availability for checkout Usage: my $issuability = Koha::Availability::Checkout->item({ item => $item, patron => $patron, duedate => $duedate # custom due date })->in_intranet; if ($issuability->available) { # yes! } else { # not available for checkout. $issuability contains all the reasons for this. } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #13 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 58454 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58454&action=edit Bug 17712: Item and biblio availability in search context Usage: my $availability = Koha::Availability::Search->item({ item => $item, })->in_opac; if ($availability->available) { # yes } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #14 from Lari Taskula <lari.taskula@jns.fi> --- I set this Bug to "In discussion" and provided my proposal as a (crude) set of patches so that hopefully it helps to understand my idea better. I am open to renaming the classes if Koha::Availability doesn't feel right and also open for alternative solutions. We need to be able to integrate availability into REST API asap. and essentially these patches make that integration less painless. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #15 from Lari Taskula <lari.taskula@jns.fi> --- (In reply to Lari Taskula from comment #14)
integration less painless. /painless/painful
Happy new year! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |16826 Depends on|16826 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16826 [Bug 16826] REST API: Add API routes for getting item availability and holdability -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.maurice@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58446|0 |1 is obsolete| | --- Comment #16 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60147 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60147&action=edit Bug 17712: Add new Koha::Exceptions To describe problems or notes to availability, we will be using Koha::Exceptions. This patch adds many useful Koha::Exceptions that we can use for this purpose. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58447|0 |1 is obsolete| | --- Comment #17 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60148 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60148&action=edit Bug 17712: Koha::Availability, a base for availability information This patch adds a new class, Koha::Availability, which is designed to contain availability information for each type of availability in an uniform way. Because of this, Koha::Availability has no actual availability calculation logic, but simply methods to get and set availability information into the object. With such design, we can next create new classes Koha::Availability::Hold and Koha::Availability::Checkout and let them inherit Koha::Availability so that they are able to handle availaibility information in an uniform way. Koha::Availability::Hold Koha::Availability::Checkout | | \_________________________________/ | Koha::Availability Koha::Availability can represent four levels of availability statuses: 1. available 2. available, with an additional note 3. available, but requires confirmation 4. unavailable Additional notes, reasons for a need to confirm and reasons for unavailabilities are kept in a HASHref, where each value in my proposal is a Koha::Exceptions::*. This allows us to easily store any additional data directly into the reason. For example, if we want to check biblio availability for hold and find out it is not available, the HASHref for unavailabilities has a Koha::Exceptions::Patron::Debt that contains parameters "current_outstanding" and "max_outstanding" which lets us pick up the information easily later on without making new queries. To test: 1. Run t/Koha/Availability.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58449|0 |1 is obsolete| | --- Comment #18 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60149 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60149&action=edit Bug 17712: Add base for item and biblio availability This patch adds two new classes: - Koha::Biblio::Availability - Koha::Item::Availability These classes represent biblio- and item-level availabilities and the purpose of this patch is simply to provide constructors that validate given biblio/item and patron parameters. Hold / checkout / search view availabilities (the actual answers to availability) will be provided in the next patches. To test: 1. Run t/db_dependent/Koha/Item/Availability.t 2. Run t/db_dependent/Koha/Biblio/Availability.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58450|0 |1 is obsolete| | --- Comment #19 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60150 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60150&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. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58451|0 |1 is obsolete| | --- Comment #20 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60151 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60151&action=edit Bug 17712: Item availability for hold Adds Koha::Item::Availability::Hold class for item hold availability. This patch adds item holdability queries in two contexts: 1. in_opac (perspective of patron themselves) 2. in_intranet (perspective of a librarian to patron) Returns a Koha::Item::Availability::Hold object, which contains all information on availability for hold in that context. This may include additional notes, reasons to ask for confirmation or reasons for unavailability. Example: To find out if patron can hold an item in OPAC, we will write: my $availability = Koha::Availability::Hold->item({ patron => $patron, item => $item, to_branch => $branchcode, # transfer allowed from holdingbranch to to_branch? })->in_opac; if ($availability->available) { # yes! } else { foreach my $reason (keys %{$availability->unavailabilities}) { # each reason for unavailability } foreach my $reason (keys %{$availability->confirmations}) { # each reason that requires confirmation } foreach my $reason (keys %{$availability->notes}) { # each additional note } } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58452|0 |1 is obsolete| | --- Comment #21 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60152 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60152&action=edit Bug 17712: Biblio availability for hold Usage: $holdability = Koha::Availability::Hold->biblio({ biblio => $biblio, patron => $patron, to_branch => "CPL", })->in_opac; if ($holdability->available) { # yup! # arrayref of Koha::Item::Availability::Hold -objects: # 1. all available items (items may contain confirmations / notes) my $item_availabilities = $holdability->item_availabilities; # 2. all unavailable items my $item_unavailabilities = $holdability->item_unavailabilites; } Returns a Koha::Biblio::Availability::Hold -object. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58453|0 |1 is obsolete| | --- Comment #22 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60153 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60153&action=edit Bug 17712: Item availability for checkout Usage: my $issuability = Koha::Availability::Checkout->item({ item => $item, patron => $patron, duedate => $duedate # custom due date })->in_intranet; if ($issuability->available) { # yes! } else { # not available for checkout. $issuability contains all the reasons for this. } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58454|0 |1 is obsolete| | --- Comment #23 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60154 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60154&action=edit Bug 17712: Item and biblio availability in search context Usage: my $availability = Koha::Availability::Search->item({ item => $item, })->in_opac; if ($availability->available) { # yes } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #24 from Lari Taskula <lari.taskula@jns.fi> --- Fixed failing tests. To test these patches, I recommend applying patches in Bug 16826 on top of these and testing it via REST API. It demonstrates the unavailability reasons nicely as it will include any additional parameter (like "max_outstanding", "current_outstanding" in Patron::Debt) in the response JSON. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |lari.taskula@jns.fi |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60150|0 |1 is obsolete| | --- Comment #25 from Lari Taskula <lari.taskula@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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60151|0 |1 is obsolete| | --- Comment #26 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60262 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60262&action=edit Bug 17712: Item availability for hold Adds Koha::Item::Availability::Hold class for item hold availability. This patch adds item holdability queries in two contexts: 1. in_opac (perspective of patron themselves) 2. in_intranet (perspective of a librarian to patron) Returns a Koha::Item::Availability::Hold object, which contains all information on availability for hold in that context. This may include additional notes, reasons to ask for confirmation or reasons for unavailability. Example: To find out if patron can hold an item in OPAC, we will write: my $availability = Koha::Availability::Hold->item({ patron => $patron, item => $item, to_branch => $branchcode, # transfer allowed from holdingbranch to to_branch? })->in_opac; if ($availability->available) { # yes! } else { foreach my $reason (keys %{$availability->unavailabilities}) { # each reason for unavailability } foreach my $reason (keys %{$availability->confirmations}) { # each reason that requires confirmation } foreach my $reason (keys %{$availability->notes}) { # each additional note } } -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60152|0 |1 is obsolete| | --- Comment #27 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60263 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60263&action=edit Bug 17712: Biblio availability for hold Usage: $holdability = Koha::Availability::Hold->biblio({ biblio => $biblio, patron => $patron, to_branch => "CPL", })->in_opac; if ($holdability->available) { # yup! # arrayref of Koha::Item::Availability::Hold -objects: # 1. all available items (items may contain confirmations / notes) my $item_availabilities = $holdability->item_availabilities; # 2. all unavailable items my $item_unavailabilities = $holdability->item_unavailabilites; } Returns a Koha::Biblio::Availability::Hold -object. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60153|0 |1 is obsolete| | --- Comment #28 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60264 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60264&action=edit Bug 17712: Item availability for checkout Usage: my $issuability = Koha::Availability::Checkout->item({ item => $item, patron => $patron, duedate => $duedate # custom due date })->in_intranet; if ($issuability->available) { # yes! } else { # not available for checkout. $issuability contains all the reasons for this. } -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60154|0 |1 is obsolete| | --- Comment #29 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 60265 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60265&action=edit Bug 17712: Item and biblio availability in search context Usage: my $availability = Koha::Availability::Search->item({ item => $item, })->in_opac; if ($availability->available) { # yes } -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #30 from Julian Maurice <julian.maurice@biblibre.com> --- Why is this bug 'In Discussion' ? Shouldn't it be 'Needs Signoff' ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #31 from Lari Taskula <lari.taskula@jns.fi> --- (In reply to Julian Maurice from comment #30)
Why is this bug 'In Discussion' ? Shouldn't it be 'Needs Signoff' ?
Hi Julian! I left this in discussion to get more feedback on the idea and the patches were attached as an example implementation. But you are right, Needs Signoff is a better status now that there are attached patches implementing this suggestion. We are actually in process of testing this feature together with VuFind via Koha REST API (Bug 16826). So far we received some valuable test feedback, and I have follow-up bugfixes coming that I will squash soon. I shall set this to needs signoff then :) Thanks for the comment! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #32 from Julian Maurice <julian.maurice@biblibre.com> --- Nice! I haven't had a chance to look at the code yet but the idea is great IMO :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60147|0 |1 is obsolete| | --- Comment #33 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62719 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62719&action=edit Bug 17712: Add new Koha::Exceptions To describe problems or notes to availability, we will be using Koha::Exceptions. This patch adds many useful Koha::Exceptions that we can use for this purpose. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60148|0 |1 is obsolete| | --- Comment #34 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62720 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62720&action=edit Bug 17712: Koha::Availability, a base for availability information This patch adds a new class, Koha::Availability, which is designed to contain availability information for each type of availability in an uniform way. Because of this, Koha::Availability has no actual availability calculation logic, but simply methods to get and set availability information into the object. With such design, we can next create new classes Koha::Availability::Hold and Koha::Availability::Checkout and let them inherit Koha::Availability so that they are able to handle availaibility information in an uniform way. Koha::Availability::Hold Koha::Availability::Checkout | | \_________________________________/ | Koha::Availability Koha::Availability can represent four levels of availability statuses: 1. available 2. available, with an additional note 3. available, but requires confirmation 4. unavailable Additional notes, reasons for a need to confirm and reasons for unavailabilities are kept in a HASHref, where each value in my proposal is a Koha::Exceptions::*. This allows us to easily store any additional data directly into the reason. For example, if we want to check biblio availability for hold and find out it is not available, the HASHref for unavailabilities has a Koha::Exceptions::Patron::Debt that contains parameters "current_outstanding" and "max_outstanding" which lets us pick up the information easily later on without making new queries. To test: 1. Run t/Koha/Availability.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #57923|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60149|0 |1 is obsolete| | --- Comment #35 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62721 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62721&action=edit Bug 17712: Add base for item and biblio availability This patch adds two new classes: - Koha::Biblio::Availability - Koha::Item::Availability These classes represent biblio- and item-level availabilities and the purpose of this patch is simply to provide constructors that validate given biblio/item and patron parameters. Hold / checkout / search view availabilities (the actual answers to availability) will be provided in the next patches. To test: 1. Run t/db_dependent/Koha/Item/Availability.t 2. Run t/db_dependent/Koha/Biblio/Availability.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60261|0 |1 is obsolete| | --- Comment #36 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62722 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62722&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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60262|0 |1 is obsolete| | --- Comment #37 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62723 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62723&action=edit Bug 17712: Item availability for hold Adds Koha::Item::Availability::Hold class for item hold availability. This patch adds item holdability queries in two contexts: 1. in_opac (perspective of patron themselves) 2. in_intranet (perspective of a librarian to patron) Returns a Koha::Item::Availability::Hold object, which contains all information on availability for hold in that context. This may include additional notes, reasons to ask for confirmation or reasons for unavailability. Example: To find out if patron can hold an item in OPAC, we will write: my $availability = Koha::Availability::Hold->item({ patron => $patron, item => $item, to_branch => $branchcode, # transfer allowed from holdingbranch to to_branch? })->in_opac; if ($availability->available) { # yes! } else { foreach my $reason (keys %{$availability->unavailabilities}) { # each reason for unavailability } foreach my $reason (keys %{$availability->confirmations}) { # each reason that requires confirmation } foreach my $reason (keys %{$availability->notes}) { # each additional note } } -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60263|0 |1 is obsolete| | --- Comment #38 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62724 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62724&action=edit Bug 17712: Biblio availability for hold Usage: $holdability = Koha::Availability::Hold->biblio({ biblio => $biblio, patron => $patron, to_branch => "CPL", })->in_opac; if ($holdability->available) { # yup! # arrayref of Koha::Item::Availability::Hold -objects: # 1. all available items (items may contain confirmations / notes) my $item_availabilities = $holdability->item_availabilities; # 2. all unavailable items my $item_unavailabilities = $holdability->item_unavailabilites; } Returns a Koha::Biblio::Availability::Hold -object. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60264|0 |1 is obsolete| | --- Comment #39 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62725 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62725&action=edit Bug 17712: Item availability for checkout Usage: my $issuability = Koha::Availability::Checkout->item({ item => $item, patron => $patron, duedate => $duedate # custom due date })->in_intranet; if ($issuability->available) { # yes! } else { # not available for checkout. $issuability contains all the reasons for this. } -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60265|0 |1 is obsolete| | --- Comment #40 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 62726 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62726&action=edit Bug 17712: Item and biblio availability in search context Usage: my $availability = Koha::Availability::Search->item({ item => $item, })->in_opac; if ($availability->available) { # yes } -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #41 from Lari Taskula <lari.taskula@jns.fi> --- Rebased on master. Squashed some small bug fixes into the commits. Like before, I recommend testing it with the REST API (Bug 16826). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |benjamin.rokseth@kul.oslo.k | |ommune.no --- Comment #42 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Sorry to see you're so alone on this, as it sounds like a very good idea! I will sign it off, though I have some concerns, particularly on performance. Passing koha objects around this way seems very javaish, and I don't really see the point, if all you really need is foreign keys. But then again, its circumstantial, and could be remedied at a later stage if needed. And it's a bit unfair on such a large codechange, which is actually relatively easy to read and follow. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62719|0 |1 is obsolete| | --- Comment #43 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63343 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63343&action=edit Bug 17712: Add new Koha::Exceptions To describe problems or notes to availability, we will be using Koha::Exceptions. This patch adds many useful Koha::Exceptions that we can use for this purpose. Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62720|0 |1 is obsolete| | --- Comment #44 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63344 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63344&action=edit Bug 17712: Koha::Availability, a base for availability information This patch adds a new class, Koha::Availability, which is designed to contain availability information for each type of availability in an uniform way. Because of this, Koha::Availability has no actual availability calculation logic, but simply methods to get and set availability information into the object. With such design, we can next create new classes Koha::Availability::Hold and Koha::Availability::Checkout and let them inherit Koha::Availability so that they are able to handle availaibility information in an uniform way. Koha::Availability::Hold Koha::Availability::Checkout | | \_________________________________/ | Koha::Availability Koha::Availability can represent four levels of availability statuses: 1. available 2. available, with an additional note 3. available, but requires confirmation 4. unavailable Additional notes, reasons for a need to confirm and reasons for unavailabilities are kept in a HASHref, where each value in my proposal is a Koha::Exceptions::*. This allows us to easily store any additional data directly into the reason. For example, if we want to check biblio availability for hold and find out it is not available, the HASHref for unavailabilities has a Koha::Exceptions::Patron::Debt that contains parameters "current_outstanding" and "max_outstanding" which lets us pick up the information easily later on without making new queries. To test: 1. Run t/Koha/Availability.t Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62721|0 |1 is obsolete| | --- Comment #45 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63345 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63345&action=edit Bug 17712: Add base for item and biblio availability This patch adds two new classes: - Koha::Biblio::Availability - Koha::Item::Availability These classes represent biblio- and item-level availabilities and the purpose of this patch is simply to provide constructors that validate given biblio/item and patron parameters. Hold / checkout / search view availabilities (the actual answers to availability) will be provided in the next patches. To test: 1. Run t/db_dependent/Koha/Item/Availability.t 2. Run t/db_dependent/Koha/Biblio/Availability.t Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62722|0 |1 is obsolete| | --- Comment #46 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63346 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63346&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/* Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62723|0 |1 is obsolete| | --- Comment #47 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63347 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63347&action=edit Bug 17712: Item availability for hold Adds Koha::Item::Availability::Hold class for item hold availability. This patch adds item holdability queries in two contexts: 1. in_opac (perspective of patron themselves) 2. in_intranet (perspective of a librarian to patron) Returns a Koha::Item::Availability::Hold object, which contains all information on availability for hold in that context. This may include additional notes, reasons to ask for confirmation or reasons for unavailability. Example: To find out if patron can hold an item in OPAC, we will write: my $availability = Koha::Availability::Hold->item({ patron => $patron, item => $item, to_branch => $branchcode, # transfer allowed from holdingbranch to to_branch? })->in_opac; if ($availability->available) { # yes! } else { foreach my $reason (keys %{$availability->unavailabilities}) { # each reason for unavailability } foreach my $reason (keys %{$availability->confirmations}) { # each reason that requires confirmation } foreach my $reason (keys %{$availability->notes}) { # each additional note } } Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62724|0 |1 is obsolete| | --- Comment #48 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63348 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63348&action=edit Bug 17712: Biblio availability for hold Usage: $holdability = Koha::Availability::Hold->biblio({ biblio => $biblio, patron => $patron, to_branch => "CPL", })->in_opac; if ($holdability->available) { # yup! # arrayref of Koha::Item::Availability::Hold -objects: # 1. all available items (items may contain confirmations / notes) my $item_availabilities = $holdability->item_availabilities; # 2. all unavailable items my $item_unavailabilities = $holdability->item_unavailabilites; } Returns a Koha::Biblio::Availability::Hold -object. Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62725|0 |1 is obsolete| | --- Comment #49 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63349 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63349&action=edit Bug 17712: Item availability for checkout Usage: my $issuability = Koha::Availability::Checkout->item({ item => $item, patron => $patron, duedate => $duedate # custom due date })->in_intranet; if ($issuability->available) { # yes! } else { # not available for checkout. $issuability contains all the reasons for this. } Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62726|0 |1 is obsolete| | --- Comment #50 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- Created attachment 63350 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63350&action=edit Bug 17712: Item and biblio availability in search context Usage: my $availability = Koha::Availability::Search->item({ item => $item, })->in_opac; if ($availability->available) { # yes } Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #51 from Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> --- tests pass. works as described. Ran some manual tests by perl evaluated code -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #52 from Lari Taskula <lari.taskula@jns.fi> --- (In reply to Benjamin Rokseth from comment #42)
Sorry to see you're so alone on this, as it sounds like a very good idea! I will sign it off, though I have some concerns, particularly on performance.
Passing koha objects around this way seems very javaish, and I don't really see the point, if all you really need is foreign keys.
But then again, its circumstantial, and could be remedied at a later stage if needed. And it's a bit unfair on such a large codechange, which is actually relatively easy to read and follow.
Thanks for the support, new ideas, and the sign-off, Benjamin, and glad to hear from you! I found this a very challenging project and surely there is room for further performance improvements as well as other changes - under heavy pressure some of the choices made may have not been optimal. Follow-ups are welcome :) BTW, this is also under busy testing by our librarians and in the following days I'll have a desk-full of test reports and possibly follow-ups coming in for this Bug :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #53 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Koha::Exceptions::WrongParameter is already present, you add BadParameter -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #54 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Lari Taskula from comment #52)
BTW, this is also under busy testing by our librarians and in the following days I'll have a desk-full of test reports and possibly follow-ups coming in for this Bug :)
No reports or follow-ups were added ? Needs feedback. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #55 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- # Failed test 'No tests run for subtest "Attempt to instantiate holdability class with valid biblionumber"' # at t/db_dependent/Koha/Biblio/Availability.t line 52. Cannot use "->find" in list context at /usr/share/koha/masterclone/Koha/Biblio/Availability.pm line 91. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #56 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- # Failed test 'No tests run for subtest "Attempt to instantiate holdability class with valid itemnumber"' # at t/db_dependent/Koha/Item/Availability.t line 52. Cannot use "->find" in list context at /usr/share/koha/masterclone/Koha/Item/Availability.pm line 85. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #57 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- t/db_dependent/Koha/Availability/Checks/Item.t ............. 1/14 # Failed test 'checked_out' # at t/db_dependent/Koha/Availability/Checks/Item.t line 48. Undefined subroutine &C4::Circulation::GetItemIssue called at /usr/share/koha/masterclone/Koha/Availability/Checks/Item.pm line 68. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #58 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- t/db_dependent/Koha/Item/Availability/Checkout.t (Wstat: 65280 Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 255 Parse errors: Bad plan. You planned 10 tests but ran 2. t/db_dependent/Koha/Item/Availability/Search.t (Wstat: 256 Tests: 10 Failed: 1) Failed test: 6 Non-zero exit status: 1 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #59 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Lari, Looks impressive. At this point it fails for various problems reported. The big discussion we face here, is: Do we want to add all this new code without using it yet? It is obviously very hard to start using it everywhere, but I guess we need some strategy in order to prevent ending up with a lot of unused code that is no longer in sync with the current routines. And at that point it will of course need some really extensive testing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=17677 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org See Also|https://bugs.koha-community |https://bugs.koha-community |.org/bugzilla3/show_bug.cgi |.org/bugzilla3/show_bug.cgi |?id=17677 |?id=19297 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=10304 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63343|0 |1 is obsolete| | Attachment #63344|0 |1 is obsolete| | Attachment #63345|0 |1 is obsolete| | Attachment #63346|0 |1 is obsolete| | Attachment #63347|0 |1 is obsolete| | Attachment #63348|0 |1 is obsolete| | Attachment #63349|0 |1 is obsolete| | Attachment #63350|0 |1 is obsolete| | --- Comment #60 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84830 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84830&action=edit Bug 17712: Add new Koha::Exceptions To describe problems or notes to availability, we will be using Koha::Exceptions. This patch adds many useful Koha::Exceptions that we can use for this purpose. Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #61 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84831 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84831&action=edit Bug 17712: Koha::Availability, a base for availability information This patch adds a new class, Koha::Availability, which is designed to contain availability information for each type of availability in an uniform way. Because of this, Koha::Availability has no actual availability calculation logic, but simply methods to get and set availability information into the object. With such design, we can next create new classes Koha::Availability::Hold and Koha::Availability::Checkout and let them inherit Koha::Availability so that they are able to handle availaibility information in an uniform way. Koha::Availability::Hold Koha::Availability::Checkout | | \_________________________________/ | Koha::Availability Koha::Availability can represent four levels of availability statuses: 1. available 2. available, with an additional note 3. available, but requires confirmation 4. unavailable Additional notes, reasons for a need to confirm and reasons for unavailabilities are kept in a HASHref, where each value in my proposal is a Koha::Exceptions::*. This allows us to easily store any additional data directly into the reason. For example, if we want to check biblio availability for hold and find out it is not available, the HASHref for unavailabilities has a Koha::Exceptions::Patron::Debt that contains parameters "current_outstanding" and "max_outstanding" which lets us pick up the information easily later on without making new queries. To test: 1. Run t/Koha/Availability.t Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #62 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84832 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84832&action=edit Bug 17712: Add base for item and biblio availability This patch adds two new classes: - Koha::Biblio::Availability - Koha::Item::Availability These classes represent biblio- and item-level availabilities and the purpose of this patch is simply to provide constructors that validate given biblio/item and patron parameters. Hold / checkout / search view availabilities (the actual answers to availability) will be provided in the next patches. To test: 1. Run t/db_dependent/Koha/Item/Availability.t 2. Run t/db_dependent/Koha/Biblio/Availability.t Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #63 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84833 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84833&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/* Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #64 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84834 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84834&action=edit Bug 17712: Item availability for hold Adds Koha::Item::Availability::Hold class for item hold availability. This patch adds item holdability queries in two contexts: 1. in_opac (perspective of patron themselves) 2. in_intranet (perspective of a librarian to patron) Returns a Koha::Item::Availability::Hold object, which contains all information on availability for hold in that context. This may include additional notes, reasons to ask for confirmation or reasons for unavailability. Example: To find out if patron can hold an item in OPAC, we will write: my $availability = Koha::Availability::Hold->item({ patron => $patron, item => $item, to_branch => $branchcode, # transfer allowed from holdingbranch to to_branch? })->in_opac; if ($availability->available) { # yes! } else { foreach my $reason (keys %{$availability->unavailabilities}) { # each reason for unavailability } foreach my $reason (keys %{$availability->confirmations}) { # each reason that requires confirmation } foreach my $reason (keys %{$availability->notes}) { # each additional note } } Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #65 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84835 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84835&action=edit Bug 17712: Biblio availability for hold Usage: $holdability = Koha::Availability::Hold->biblio({ biblio => $biblio, patron => $patron, to_branch => "CPL", })->in_opac; if ($holdability->available) { # yup! # arrayref of Koha::Item::Availability::Hold -objects: # 1. all available items (items may contain confirmations / notes) my $item_availabilities = $holdability->item_availabilities; # 2. all unavailable items my $item_unavailabilities = $holdability->item_unavailabilites; } Returns a Koha::Biblio::Availability::Hold -object. Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #66 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84836 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84836&action=edit Bug 17712: Item availability for checkout Usage: my $issuability = Koha::Availability::Checkout->item({ item => $item, patron => $patron, duedate => $duedate # custom due date })->in_intranet; if ($issuability->available) { # yes! } else { # not available for checkout. $issuability contains all the reasons for this. } Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #67 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84837 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84837&action=edit Bug 17712: Item and biblio availability in search context Usage: my $availability = Koha::Availability::Search->item({ item => $item, })->in_opac; if ($availability->available) { # yes } Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #68 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84838 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84838&action=edit Bug 17712: (follow-up) Remove unused exceptions -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #69 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 84839 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84839&action=edit Bug 17712: (follow-up) Make test pass Test plan: Run these tests: t/Koha/Availability.t t/db_dependent/Koha/Availability/Checks/Biblio.t t/db_dependent/Koha/Availability/Checks/Biblioitem.t t/db_dependent/Koha/Availability/Checks/Checkout.t t/db_dependent/Koha/Availability/Checks/IssuingRule.t t/db_dependent/Koha/Availability/Checks/Item.t t/db_dependent/Koha/Availability/Checks/LibraryItemRule.t t/db_dependent/Koha/Availability/Checks/Patron.t t/db_dependent/Koha/Biblio/Availability.t t/db_dependent/Koha/Biblio/Availability/Hold.t t/db_dependent/Koha/Biblio/Availability/Search.t t/db_dependent/Koha/Item/Availability.t t/db_dependent/Koha/Item/Availability/Checkout.t t/db_dependent/Koha/Item/Availability/Hold/Intranet/HoldPolicyOverride.t t/db_dependent/Koha/Item/Availability/Hold/Opac/HoldRules.t t/db_dependent/Koha/Item/Availability/Hold/Opac/ItemStatus.t t/db_dependent/Koha/Item/Availability/Hold/Opac/LibraryItemRules.t t/db_dependent/Koha/Item/Availability/Search.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Lari Taskula <lari.taskula@hypernova.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|lari.taskula@hypernova.fi |koha-bugs@lists.koha-commun | |ity.org --- Comment #70 from Lari Taskula <lari.taskula@hypernova.fi> --- I'm no longer able to work on this, so I'm setting assignee to default. Feel free to continue this work. We've been running it in production since 2017 and it's used by VuFind instance of National Library of Finland together with Bug 16826. There are some fixes and improvements (that need rebasing) available at https://github.com/KohaSuomi/Koha/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |arthur.suzuki@biblibre.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 --- Comment #71 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- *** Bug 19297 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |19297 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19297 [Bug 19297] [OMNIBUS] Standardize "can place hold" calculations -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=23336 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Katie Bliss <kebliss@dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss@dmpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17712 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|arthur.suzuki@biblibre.com |koha-bugs@lists.koha-commun | |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org