- Koha-devel - lists.koha-community.org

Re: [Koha-devel] Availability in Koha Was: Re: [Koha-patches] [PATCH 2/2] Fixes bug 4481: Limit to Available filters out many available items.
by Joe Atzberger 24 May '10

24 May '10

On Mon, May 24, 2010 at 12:56 PM, Liz Rea <lrea(a)nekls.org> wrote: > While I agree with you that the 952$q as a measure of availability is > legitimate, I still think Koha *does* need one place for external > applications (like Autographics) to look for availability. You say this as though "availability" were one thing. If it were, then I would agree it would make sense. For your purposes, I think maybe we are talking specifically about a new availability-for-ILL-checkout? Not holds? Not renewals? This is different than the other kinds of availability we listed, closest to "available for transfer-for-checkout", but afaik not otherwise represented in Koha. BTW, I forgot to add "available-for-renewal" in the availability matrix also. One question is whether ILL availability is always computable from other existing statuses. I.E, would a "virtual" field suffice? Previous implementation suggests that users desire individual manual control (i.e. notforloan, notforhold... in this case "notforILL") that lives at the data row level and is toggleable "actual" data. This makes transactions more of a pain, but hey, it's what users seem to want. > Our statewide system ties into at least 7 different kinds of automation > systems, and according to information given to us by the statewide ILL > team, Koha is the only one that doesn't give authoritative > availability information in a single field. Whether that's correct or > not I admit I don't have first hand data to support the assertion. > Any code or documentation we might use as a reference implementation? > Shortcomings of that system aside, in my mind a complex system like > statewide ILL *should* only have to look at one field, instead of > compute availability from 20 different places. An ILL system might very well build logic that determines effective availability (and priority!) from it's own rules, involving geography, branch "system" affiliation, transfer costs, patron type/status, number of remaining copies (i.e., allow ILL as long as there is another copy on the shelf), balance of overall ILL transactions between branches or systems, round robin, age of the title since publication, age of the item since addition, etc. That is, in large part, the point of a separate ILL control system. If you want each discrete ILS to give one binary status, then the ILL system is not a controlling mechanism and it loses the ability to build more sophisticated rules. > Place the onus of > computing availability on the client ILS, instead of on the ILL > system. Why shouldn't we make it simple to interconnect these systems, > especially since most (if not all) of the other ILS's do? > It is already possible (though arguably not "simple") to integrate disparate systems for resource sharing via SIP2. OCLC uses SIP2 extensively to fetch real-time item availability info, and that standard still differentiates between: - circ status - checkout/access fee type - checkout/access fee amount - hold queue length - date due - recall date - hold pickup date - other item properties (size, weight, etc) ILL systems can and should care about different things. And it's very nice to hear from you, Joe. :) > You too, Liz. --Joe > On Mon, May 24, 2010 at 10:19 AM, Joe Atzberger <ohiocore(a)gmail.com> > wrote: > > 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(a)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(a)biblibre.com> wrote: > >>> > >>> Le 19/05/2010 00:04, Ian Walls a écrit : > >>> > From: Ian Walls <Ian.Walls(a)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. > > >

1 0

Re: [Koha-devel] Availability in Koha Was: Re: [Koha-patches] [PATCH 2/2] Fixes bug 4481: Limit to Available filters out many available items.
by Joe Atzberger 24 May '10

24 May '10

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(a)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(a)biblibre.com> wrote: >> >> Le 19/05/2010 00:04, Ian Walls a écrit : >> >>> > From: Ian Walls <Ian.Walls(a)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. >> >>

1 0

[Koha] The Great Bugzilla move
by Chris Cormack 23 May '10

23 May '10

I notice that it has been re-enabled now, and my admin access revoked. I also note the old wiki has had the link to the new wiki removed, and my account there has been deleted. So just to avoid confusion, http://bugs.koha-community.org is the bugzilla that I will be using as elected release manager for the 3.4 release. I will of course be making use of the other .koha-comunity.org sites too. If anyone would like a shell account on the machine running download or bugs please let me know. I will be writing a tutorial on how you can now interact with the new bugzilla using email. And will post that on http://wiki.koha-community.org Thanks Chris On 21 May 2010 15:27, Chris Cormack <chris(a)bigballofwax.co.nz> wrote: > On 21 May 2010 14:50, mason(a)KohaAloha.com <mason(a)kohaaloha.com> wrote: >> >> On 2010-05-21, at 2:32 PM, Rick Welykochy wrote: >> >>> Chris Cormack wrote: >>> >>>> http://bugs.koha-community.org is live. With all the bugs imported from >>>> bugs.koha.org >>> >>> Thanks for the hard yards, Chris. >>> >>> I did a spot check and was able to find a bug I know about. >>> >>> Note that it appears that one can still create a new bug using the >>> old system. >> >> >>> Can you either disable access to it, or better still >>> make it read only? >> >> >> Nope, Thats a switch-over task that only the PTFS team can to. >> >> > Actually I still have my login, so I have disabled it (nothing is lost > its just in shutdown mode) > > Thanks for the reminder Rick > > Chris >

6 5

Mailing list migration End !
by Nahuel ANGELINETTI 21 May '10

21 May '10

Hi, As you know, I was migrating the mailing-lists this morning. The job is done, and know you are requested to use koha-devel(a)lists.koha-community.org and not anymore koha-devel(a)lists.koha.org. Please transmit the message to other users. bests, -- Nahuel ANGELINETTI

1 0

This is another test
by Nahuel ANGELINETTI 21 May '10

21 May '10

-- Nahuel ANGELINETTI

1 0

The Great Mailing-Lists move
by Nahuel ANGELINETTI 21 May '10

21 May '10

Ok, Today is the day I will be shifting all the mailing-lists from lists.koha.org to lists.koha-community.org. I plan to start the shift in 1 hour (10am UTC+1). It would help immensely if no one used lists.koha.org after that time, and I will email when lists.koha-community.org is up and ready to go. -- Nahuel ANGELINETTI

1 0

The Great Bugzilla move
by Chris Cormack 21 May '10

21 May '10

Ok, Today is the day I will be shifting all the bugs from bugs.koha.org to bugs.koha-community.org. I plan to start the shift in 1 hour (10am NZST). It would help immensely if no one used bugs.koha.org after that time, and I will email when bugs.koha-community is up and ready to go. Chris

4 5

perldoc.koha-community.org
by Galen Charlton 20 May '10

20 May '10

Hi, I've set up a new website for Koha's POD: http://perldoc.koha-community.org/. This is refreshed nightly from a current Git fetch and formatted using Pod::Simple::HTMLBatch. I've (arbitrarily) chosen to HTMLify the POD for the master branch, 3.0.x, and all tags starting with 'v'. If you have suggestions or comments, please respond to me or the list. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 0

Availability in Koha Was: Re: [Koha-patches] [PATCH 2/2] Fixes bug 4481: Limit to Available filters out many available items.
by Liz Rea 20 May '10

20 May '10

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(a)biblibre.com> wrote: > Le 19/05/2010 00:04, Ian Walls a écrit : > > From: Ian Walls <Ian.Walls(a)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(a)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(a)bywatersolutions.com > Twitter: @sekjal > _______________________________________________ > Koha-patches mailing list > Koha-patches(a)lists.koha.org > http://lists.koha.org/mailman/listinfo/koha-patches

2 1

Patrons with no Checkouts report
by Toni 19 May '10

19 May '10

Hello, After looking into the code of the predefined report "Patrons with No Checkouts" (borrowers_out.pl), I wonder whether the way it is generated (at least in Koha version 3.0.5) is a Bug: It only takes into consideration "old_issues" table, which means that Patrons having items for the first time will appear in the list of "Patrons with no Checkouts". Taking this case (first time users) into account should be as easy as filtering out by the "issues" table in addition to the old_issues table. Is it a BUG? Should I therefore report it? If I report it, I could attach the necessary modification to make it work taking in consideratin first time borrowers, Do you accept "casual" patches from external people? Thanks, Toni

1 0