[Koha-devel] Availability in Koha Was: Re: [Koha-patches] [PATCH 2/2] Fixes bug 4481: Limit to Available filters out many available items.

Joe Atzberger ohiocore at gmail.com
Mon May 24 17:22:05 CEST 2010


Hey Liz --

>
It sounds like you would be trying to code AutoGraphics logic into Koha.

>
Another user group might prefer the granularity that currently exists, or
use software that requires it.  Broadly speaking, we can imagine
"availability" many different ways:

>
   - available for checkout
   - available for hold
   - available for in house use
   - available for pickup (on hold)
   - available for transfer-for-checkout
   - available for transfer-for-hold
   - available for transfer-for-in-house-use
   - available for recall
   - available for electronic viewing
   - available for electronic download

Then matrix out all those possibilities with available-for-free,
available-for-fee, and available-to-certain-patron-types, etc.

>
In my opinion, it is not logical or desirable for a system to compress all
those values into one MARC subfield, for any purpose.  Arguably the best
standards-exposed item availability information is from the SIP2 Item
Information (17/18) message pair, and that does not compress hold, checkout,
recall and fine info.

>
If you still want to pursue representation in MARC, it should not override
the 952$q that for Koha otherwise just means date due.  That info is still
quite valuable in a distinct form.

>
Ian, I agree with some of your premises, but I don't see how adding a
sometimes-user-configurable status with partial overlap of other statuses
and undefined interaction properties under undefined permissions controls
would make things "clearer".  Think about it this way: if AutoGraphics were
another open source project, I'm pretty sure we would be talking about
patching it, not Koha.  Since it is not, and since it is in the company's
financial interest and expertise to do so, I think this one is on them.

>
--joe


2010/5/19 Liz Rea <lrea at nekls.org>

>

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 at biblibre.com> wrote:
>>
>> Le 19/05/2010 00:04, Ian Walls a écrit :
>>
>>> > From: Ian Walls <Ian.Walls at 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.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100524/73a06847/attachment-0003.htm>


More information about the Koha-devel mailing list