Availability in Koha Was: Re: [Koha-patches] [PATCH 2/2] Fixes bug 4481: Limit to Available filters out many available items.
While we're talking about availability, thought I'd put this out there. Our statewide ILL system would really appreciate a single field for availability on items: a "yes, you can have that for ILL" or "No, I'm sorry, that item is lost, checked out, out for repair, local use only, In transit, or any one of the plethora of other reasons why this item isn't available." The statewide system currently uses AutoGraphics, which can only check one field. We are currently having them check the 952$q. Here's a brief rundown from the coordinator of the statewide ILL: "Since Koha puts status information into different subfields (rather than putting different statuses in the same subfield), we had to pick on subfield to look at. The KEGGr group decided that the best subfield to use was the 952$q. When an item is checked out, the date due appears in that subfield and AGent marks it as Not Available; if the $q is missing, the item is presumed available. My understanding is that other statuses such as Lost or In Transit appear in different subfields. Other Z target catalogs use a single subfield for status information, so when we look in the 852$s (for example), we might see On Shelf, or Checked Out, or Lost, or Mending, etc. Since there's just a single place to look, we can determine all of the different statuses and route requests accordingly." I wanted to make sure that an authoritative availability field is added if availability is revamped. It would make our life a whole lot easier. Liz Rea NEKLS On May 19, 2010, at 7:53 AM, Ian Walls wrote:
Thanks! I was sure there was an explanation for why the code was originally commented out, and a more comprehensive system for determining 'availability' is definitely called for. I had some complaints from folks on our end that the link wasn't working at all, and the functionality I get by adding those lines back in is better for them that otherwise.
I'll temporarily make use of my patch for these folks until a better one is ready. Thanks for the update!
-Ian
On Tue, May 18, 2010 at 7:08 PM, LAURENT Henri-Damien <henridamien.laurent@biblibre.com> wrote: Le 19/05/2010 00:04, Ian Walls a écrit :
From: Ian Walls <Ian.Walls@med.nyu.edu>
--- C4/Search.pm | 25 ++++++++++++------------- 1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/C4/Search.pm b/C4/Search.pm index 229ee40..e7c9c76 100644 --- a/C4/Search.pm +++ b/C4/Search.pm @@ -1256,21 +1256,20 @@ sub buildQuery { my $group_OR_limits; my $availability_limit; foreach my $this_limit (@limits) { -# if ( $this_limit =~ /available/ ) { -# -## 'available' is defined as (items.onloan is NULL) and (items.itemlost = 0) -## In English: -## all records not indexed in the onloan register (zebra) and all records with a value of lost equal to 0 -# $availability_limit .= -#"( ( allrecords,AlwaysMatches='' not onloan,AlwaysMatches='') and (lost,st-numeric=0) )"; #or ( allrecords,AlwaysMatches='' not lost,AlwaysMatches='')) )"; -# $limit_cgi .= "&limit=available"; -# $limit_desc .= ""; -# } -# + if ( $this_limit =~ /available/ ) { + +# 'available' is defined as (items.onloan is NULL) and (items.itemlost = 0) +# In English: +# all records not indexed in the onloan register (zebra) and all records with a value of lost equal to 0 + $availability_limit .= +"( ( allrecords,AlwaysMatches='' not onloan,AlwaysMatches='') and (lost,st-numeric=0) )"; #or ( allrecords,AlwaysMatches='' not lost,AlwaysMatches='')) )"; + $limit_cgi .= "&limit=available"; + $limit_desc .= ""; + } + # group_OR_limits, prefixed by mc- # OR every member of the group -# elsif ( $this_limit =~ /mc/ ) { - if ( $this_limit =~ /mc/ ) { + elsif ( $this_limit =~ /mc/ ) { $group_OR_limits .= " or " if $group_OR_limits; $limit_desc .= " or " if $group_OR_limits; $group_OR_limits .= "$this_limit"; Hi Ian. Nahuel will work on a real fix for availability. Since at the moment customers are complaining (quite fairly) that availability cannot be at biblio level but should rather be at item level. And they are correct. But When indexing elements only at biblio level, we cannot provide them with the best accurate information. So Nahuel already did some work on that. But it need some improvement, which he will do soon.
Koha-patches mailing list Koha-patches@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-patches
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth # 817 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal _______________________________________________ Koha-patches mailing list Koha-patches@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-patches
Liz, I've been thinking about that for a while now. I'd like to see a partially user-configurable "status" setting, that includes some core status (checked out, in transit, on order, etc.), as well as the ability to define new ones. Status would be a code, a staff client name, an OPAC name, and a series of toggles indicated what that status means. This would include things like: Can Be Checked Out Can Be Reserved Can Be Used in the library (reference) Can Be Accessed Remotely (for online resources) etc. etc. This list would be finite, and comprised of the various actions that can be done on an item depending on it's nature. The list above is just what I can remember right now after a long day. The tricky parts are of course automatically changing between these status on events from the system (which requires that the code knows that certain values will be in the database; perhaps add some kind of 'lock' field to prevent GUI users from accidentally deleting system-dependent data?), and what to do about Zebra indexing for this field. But it would provide a much clearer definition of what "available" is, and would also make some other external systems happier. What do others think of this? Am I missing a key issue that would prevent this from working? Cheers, -Ian On Wed, May 19, 2010 at 12:59 PM, Liz Rea <lrea@nekls.org> wrote:
While we're talking about availability, thought I'd put this out there.
Our statewide ILL system would really appreciate a single field for availability on items: a "yes, you can have that for ILL" or "No, I'm sorry, that item is lost, checked out, out for repair, local use only, In transit, or any one of the plethora of other reasons why this item isn't available."
The statewide system currently uses AutoGraphics, which can only check one field. We are currently having them check the 952$q. Here's a brief rundown from the coordinator of the statewide ILL:
"Since Koha puts status information into different subfields (rather than putting different statuses in the same subfield), we had to pick on subfield to look at. The KEGGr group decided that the best subfield to use was the 952$q. When an item is checked out, the date due appears in that subfield and AGent marks it as Not Available; if the $q is missing, the item is presumed available. My understanding is that other statuses such as Lost or In Transit appear in different subfields.
Other Z target catalogs use a single subfield for status information, so when we look in the 852$s (for example), we might see On Shelf, or Checked Out, or Lost, or Mending, etc. Since there's just a single place to look, we can determine all of the different statuses and route requests accordingly."
I wanted to make sure that an authoritative availability field is added if availability is revamped. It would make our life a whole lot easier.
Liz Rea NEKLS
On May 19, 2010, at 7:53 AM, Ian Walls wrote:
Thanks! I was sure there was an explanation for why the code was originally commented out, and a more comprehensive system for determining 'availability' is definitely called for. I had some complaints from folks on our end that the link wasn't working at all, and the functionality I get by adding those lines back in is better for them that otherwise.
I'll temporarily make use of my patch for these folks until a better one is ready. Thanks for the update!
-Ian
On Tue, May 18, 2010 at 7:08 PM, LAURENT Henri-Damien < henridamien.laurent@biblibre.com> wrote:
Le 19/05/2010 00:04, Ian Walls a écrit :
From: Ian Walls <Ian.Walls@med.nyu.edu>
--- C4/Search.pm | 25 ++++++++++++------------- 1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/C4/Search.pm b/C4/Search.pm index 229ee40..e7c9c76 100644 --- a/C4/Search.pm +++ b/C4/Search.pm @@ -1256,21 +1256,20 @@ sub buildQuery { my $group_OR_limits; my $availability_limit; foreach my $this_limit (@limits) { -# if ( $this_limit =~ /available/ ) { -# -## 'available' is defined as (items.onloan is NULL) and (items.itemlost = 0) -## In English: -## all records not indexed in the onloan register (zebra) and all records with a value of lost equal to 0 -# $availability_limit .= -#"( ( allrecords,AlwaysMatches='' not onloan,AlwaysMatches='') and (lost,st-numeric=0) )"; #or ( allrecords,AlwaysMatches='' not lost,AlwaysMatches='')) )"; -# $limit_cgi .= "&limit=available"; -# $limit_desc .= ""; -# } -# + if ( $this_limit =~ /available/ ) { + +# 'available' is defined as (items.onloan is NULL) and (items.itemlost = 0) +# In English: +# all records not indexed in the onloan register (zebra) and all records with a value of lost equal to 0 + $availability_limit .= +"( ( allrecords,AlwaysMatches='' not onloan,AlwaysMatches='') and (lost,st-numeric=0) )"; #or ( allrecords,AlwaysMatches='' not lost,AlwaysMatches='')) )"; + $limit_cgi .= "&limit=available"; + $limit_desc .= ""; + } + # group_OR_limits, prefixed by mc- # OR every member of the group -# elsif ( $this_limit =~ /mc/ ) { - if ( $this_limit =~ /mc/ ) { + elsif ( $this_limit =~ /mc/ ) { $group_OR_limits .= " or " if $group_OR_limits; $limit_desc .= " or " if $group_OR_limits; $group_OR_limits .= "$this_limit"; Hi Ian. Nahuel will work on a real fix for availability. Since at the moment customers are complaining (quite fairly) that availability cannot be at biblio level but should rather be at item level. And they are correct. But When indexing elements only at biblio level, we cannot provide them with the best accurate information. So Nahuel already did some work on that. But it need some improvement, which he will do soon.
Koha-patches mailing list Koha-patches@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-patches
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth # 817 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal _______________________________________________ Koha-patches mailing list Koha-patches@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-patches
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth # 817 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
participants (2)
-
Ian Walls -
Liz Rea