Hi We are having a problem with our item types. From what I can see the item types information is stored in biblioitems.itemtypes. Our items types are long term, short term, Reference and audio visual. These item types are used to define the loan characteristics. This information is stored in 995Z in our export from our current system (Alice/Oasis). The item type is linked to each individual item along with its barcode, location etc. We have all of our tab 10 items in 995. We cannot get Koha to recognise this as an item type as it is in the items table as opposed to the biblioitems table. It needs to be in 952b as far as we can figure out. If we define is as being biblioitems.itemtype then it can't be in tab 10 or 995. What can we do to fix it? We have set the borrowing rules but nothing can be lent until koha can recognise the item type! Please help. Many thanks Sandra Turner The Library Griffith College Dublin South Circular Road Dublin 8 Tel : +353 (0)1 4150490/1 Fax: +353 (0)1 4549595 Web: www.gcd.ie/library <http://www.gcd.ie/library> Email: sandra.turner@gcd.ie <mailto:sandra.turner@gcd.ie>
Robert McKenna a écrit :
Hi
We are having a problem with our item types. From what I can see the item types information is stored in biblioitems.itemtypes. Our items types are long term, short term, Reference and audio visual. These item types are used to define the loan characteristics. This information is stored in 995Z in our export from our current system (Alice/Oasis). The item type is linked to each individual item along with its barcode, location etc. We have all of our tab 10 items in 995. We cannot get Koha to recognise this as an item type as it is in the items table as opposed to the biblioitems table. It needs to be in 952b as far as we can figure out. If we define is as being biblioitems.itemtype then it can't be in tab 10 or 995. What can we do to fix it? We have set the borrowing rules but nothing can be lent until koha can recognise the item type!
Please help.
Many thanks
Hi In order to solve this problem, you have to audit your base to know if you can have different itemtypes 995$z for a biblio. If it would be the case, then you would have IMHO (but Joshua or more US-MARC professionnal could tell you) to create as many biblios as different itemtypes you have in for one and store them.. It it is not the case, "all you have to do" is take field 995$z value, delete subfield 995$z and add the good itemtype subfield with the value you stored to the marcrecord. Therefore, you have to modify bulkmarcimport.pl Anyone having a better idea ? HTH. -- Henri-Damien LAURENT
Hi all, in case it hasn't been obvious up until now, I'm helping Rob and Sandra out with their move to Koha. On Fri, 04 Aug 2006, Henri-Damien LAURENT wrote:
Robert McKenna a écrit :
The item type is linked to each individual item along with its barcode, location etc. We have all of our tab 10 items in 995. We cannot get Koha to recognise this as an item type as it is in the items table as opposed to the biblioitems table.
This problem seems (if I understand correctly) to be a difference in design. - the alice/oasis system relates: biblio -> item -> itemtype -> borrowingrules - koha relates: biblio -> bibliotype -> borrowingrules So apparently Oasis/Alice allows more granular application of borrower rules (per copy as opposed to per title).
In order to solve this problem, you have to audit your base to know if you can have different itemtypes 995$z for a biblio.
If it would be the case, then you would have IMHO (but Joshua or more US-MARC professionnal could tell you) to create as many biblios as different itemtypes you have in for one and store them..
This doesn't seem like a very attractive solution. A possible workaround which occurs to me is to make use of the fact that rules appear to be branch-specific. So, you create several branches XXX-RT (regular term), XXX-ST (short term), XXX-REF (reference) for the one physical library. Then, you assign items to different branches based on their previous "item type". This is a bit of a kludge though. Does anyone see this causing us problems? Could I ask the Koha developers: Is it a deliberate design decision that rules must be assigned per bibliotype rather than per item? Would you consider a patch which changed to the more granular per-itemtype rule definition or does this go against a design the Koha project has chosen. Would it be possible to combine both so that rules are applied based on biblio and item types? Gavin
Hi Gavin, On Mon, Aug 14, 2006 at 02:24:14PM +0100, Gavin McCullagh wrote:
This problem seems (if I understand correctly) to be a difference in design.
- the alice/oasis system relates: biblio -> item -> itemtype -> borrowingrules - koha relates: biblio -> bibliotype -> borrowingrules
You've hit on a major limitation of the Koha 2.2 series. The good news is it's already fixed in the CVS version for the 3.0 series. That is, you can specify circ rules on a per-item basis as well as a per-biblioitem basis. If you need to run 2.2, you should be able to merge in the changes from CVS into your local copy pretty simply ... probably much more simply than rolling your own. If you do manage to do this, I'd be very interested in a patch for this ... Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi, On Mon, 14 Aug 2006, Joshua Ferraro wrote:
You've hit on a major limitation of the Koha 2.2 series. The good news is it's already fixed in the CVS version for the 3.0 series. That is, you can specify circ rules on a per-item basis as well as a per-biblioitem basis.
Great!
If you need to run 2.2, you should be able to merge in the changes from CVS into your local copy pretty simply ... probably much more simply than rolling your own. If you do manage to do this, I'd be very interested in a patch for this ...
Hmmm. How stable is 3.0 at this point? Do you have a target date for release? Are most of the planned new features in yet? We're thinking in terms of use in September which I presume it won't be released for but if it were reasonably stable we might consider using it from CVS and chasing bugs when they hit us. Alternatively, backporting it to 2.2 might be worthwhile, particularly given that there is a reference 3.0 implentation which we could try and be database compatible with. I'd have to look into how involved that would be. Gavin
On Mon, Aug 14, 2006 at 07:06:22PM +0100, Gavin McCullagh wrote:
Hmmm. How stable is 3.0 at this point? Do you have a target date for release? Are most of the planned new features in yet? We're thinking in terms of use in September which I presume it won't be released for but if it were reasonably stable we might consider using it from CVS and chasing bugs when they hit us. Just to clarify our release schedule, 2.4 is 2.2.x with Zebra support and it should be released shortly after 2.2.6 -- apart from a few minor bugs it's pretty much ready to go right now. However, because it includes Zebra support, the implementation path is _very_ steep.
2.4 lays the groundwork for 3.0, which will include Zebra support, as well as the new features and API stuff that's been committed to HEAD over the past year or so since we branched the 2.2 series ... one of those features being the item-level circ rules stuff. We'll definitely have a 3.0 release by the end of the year, but I suspect the implementation path will still be extremely high as we haven't had much financial backing for optimizing installation and configuration of the Zebra-based Koha.
Alternatively, backporting it to 2.2 might be worthwhile, particularly given that there is a reference 3.0 implentation which we could try and be database compatible with. I'd have to look into how involved that would be. I think this is your best bet. It should be pretty simple ... and like I said, I'd love to have a patch to apply this feature to the rel_2_2 branch ... maybe Paul would even let us add it to rel_2_2 after 2.2.6 is released ...
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Seems like many people have had problems to include the /usr/local/koha/intranet/modules path to the @INC - including me using Debian Sarge - but at least I have a work-around which seems to do the trick... Giving up adding the path to @INC I considered adding the "use lib" command in all perl-files but there are too many of them. My work-around is simply doing search-and-replace on multiple files, i.e. I executed the following command standing in /usr/local/koha: rpl -eR -xpl '#!/usr/bin/perl' '#!/usr/bin/perl\nuse lib "/usr/local/koha/intranet/modules";' * The command recursively replaces #!/usr/bin/perl with #!/usr/bin/perl use lib "/usr/local/koha/intranet/modules"; in all files with .pl as extension. You may have to install the "rpl" program, but it's available as a package at least in Debian. This worked for me, hopefully it will help others as well... Best wishes, /Anders Wandahl "e-Math for Africa" http://math.golonka.se
On Mon, Aug 14, 2006 at 07:42:45AM -0700, Joshua Ferraro said:
Hi Gavin,
On Mon, Aug 14, 2006 at 02:24:14PM +0100, Gavin McCullagh wrote:
This problem seems (if I understand correctly) to be a difference in design.
- the alice/oasis system relates: biblio -> item -> itemtype -> borrowingrules - koha relates: biblio -> bibliotype -> borrowingrules
You've hit on a major limitation of the Koha 2.2 series. The good news is it's already fixed in the CVS version for the 3.0 series. That is, you can specify circ rules on a per-item basis as well as a per-biblioitem basis.
If you need to run 2.2, you should be able to merge in the changes from CVS into your local copy pretty simply ... probably much more simply than rolling your own. If you do manage to do this, I'd be very interested in a patch for this ...
Just FYI Its designed to be biblio -> biblioitem -> itemtype -> borrowing rules This is how koha is used by the libraries I support running 2.2 So it can be done in 2.2, Itemtype is at the biblioitem level not at the biblio level for precisely this reason. You dont want to have to have a differe biblio for each type of an item. If you jump on irc sometime Gavin I can show you it working Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
participants (6)
-
Anders Wandahl -
Chris Cormack -
Gavin McCullagh -
Henri-Damien LAURENT -
Joshua Ferraro -
Robert McKenna