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

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

Restructuring C4
by Ian Walls 21 Sep '11

21 Sep '11

Fellow Developers, Last night, I stayed up late running circ/circulation.pl through NYTProf, to get an idea where we may be able to optimize circulation for speed. After much frustration (darn session IDs...), I was able to get a report. The results were... not exactly what I expected. It seems that much of the time spent running circ/circulation.pl is spent BEGINing the various C4 modules, multiple times. C4::Items, for example, is BEGuN 14 times in the execution of circ/circulation.pl. More stats: C4::Accounts - 8 BEGINs C4::Acquisition - 14 BEGINs C4::Auth - 14 BEGINs C4::Biblio - 14 BEGINs C4::Branch - 5 BEGINs C4::Circulation - 22 BEGINs C4::Context - 18 BEGINs C4::Dates - 12 BEGINs ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, and C4::Search::PazPar2 are BEGuN several times, without any calls to any of their subroutines. Some modules, it seems, don't have an END at the end... I was also able to get a Graphviz file out, showing all the package calls (folks may remember my keen interest in such things from KohaCon). Running it through sccmap to detect cycles, I found a very long one between several of the modules. About 8 packages long. All this indicate to me that we REALLY need to start thinking about imposing some kind of structure on C4. I'm thinking something with two-levels: Level 1 : Calls to the database, other direct interaction with stored data Level 2: Calls to Level 1 functions to manipulate data all our scripts would then be modified to call only Level 2, which would take care of talking to Level 1. At the worst, a particular Level 1 package would be BEGuN as many times as there were Level 2 packages BEGuN in the script (and we could certainly do better). It would eliminate all the cycles, as well. I can provide access to my report for anyone who needs it, or more details about how I obtained it. Whatever any of you need to keep this conversation going. This is a big deal, in my opinion, and we need to start detangling our code before too much long, or we're going to get seriously bogged down. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

11 25

KohaCon11 hackfest: discussion
by Paul Poulain 10 Jun '11

10 Jun '11

Hello everybody, 3 weeks ago we had our 1st IRC meeting about the next KohaCon in India. It seems I've been selected to start the discussion about the Hackfest ! We've had 3 KohaCon already : one in France (2006) one in USA (2009), one in NZ (2010). In Marseille, it lasted one week and was mostly about hacking. In USA it lasted 3 days, we had one day (and a half ?) teaching new developers how to hack, then one day hacking In NZ it lasted 3 days too. the 1st day was dedicated to some -technical- lightning talks (http://www.kohacon10.org.nz/2010/hackfest/index.html) then teaching new hackers, then doing a few hacking What should be the hackfest in India then ? We have two goals during those meetings: welcome new developers, and do some real hacking: it's very efficient to work in the same room and without clock/time differences ! I proposed during the first IRC meeting to split the hackfest in 2 sub-parts, each of them dealing with one goal: * Hackfest part 1 = "become a Koha developper" * Hackfest part 2 = "do some hacking". We could say part1 is about theory, and part2 is about practising what we've learned on part1 ;-) (and of course, ppl coming for part1 would/should/could stay for part2 !) The 1st part would be dedicated to teaching Koha to ppl wanting to know how to join: things like using git, Koha source code organisation, Koha database, working with templates, dealing with translations, submitting patches. kmkale suggested to have 2 days for this part, just before sunday (that would be a day-off) The 2nd part would be dedicated to hacking: showing what is underway, showing POC if applicable (Proof of Concept), playing with bugzilla, writing unit tests,... How long could/should it last ? There are 2 opinions here: - staying & taking time is expensive, so not too long - once you're here, we must make the trip worth, so as long as possible What's your opinion on this matter ? Mine is that once we're here, we must stay as long as possible, those meetings are precious. So how long should this part last ? kmkale said there will be a room available for us for as long as we want. My proposition would be to say 3 days (mon-wed): not too short, we will be able to do useful things, not too long, we'll be back home on tuesday, before or for the next week-end, back to work next monday. What's your opinion on those ideas ? anything to add ? Feel free to give your opinion, nothing has been decided yet ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

6 12

Warnings about Koha to MARC links
by Owen Leonard 07 Apr '11

07 Apr '11

I have a question about Koha/MARC links On marctagstructure.pl it says "If you change the link between a MARC subfield and a non-MARC field, ask your administrator to run misc/batchRebuildBiblioTables.pl script." On marc_subfields_structure.pl, next to the "link" field, it says "Warning: This value should not change after data has been added to your catalog." Are these not talking about the same thing? Which is correct? I would like to remove the warning from marctagstructure.pl since it pertains directly to subfield editing, but I want to make sure the note on marc_subfields_structure.pl is accurate. Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 1

Accounts rewriting - comments wanted.
by Robin Sheat 01 Apr '11

01 Apr '11

I'm in the process of rewriting the accounts system to improve its flexibility, and getting rid of some cruft. Also to make it easier to work with from a developer point of view. The ability to do things like partial payments (which I know have been implemented about three other times, but as more putty on the existing system) and other useful things is what's aiming to come out of this, as well as having a nicely maintainable subsystem. I'm attaching the perldoc of what I have so far, I'm interested in seeing if anyone has any ideas on problems that this design might have that I should work around before it gets too much further along. I also note that the accounts system seems to handle the returning of lost items, which strikes me as the wrong place to put it, so I'll try to pull that out to somewhere more sensible, or at the least isolate it. Mostly I'm just making sure that it'll be able to reproduce all the existing functionality, which seems to have accreted in that module, but if you have any ideas for other things that can be fitted in naturally as part of this, they may be considered too. $ perldoc -t -T Accounts.pm NAME C4::Accounts - Functions for dealing with borrower accounts in Koha SYNOPSIS use C4::Accounts; DESCRIPTION The functions here handle the account for a borrower. Adding fines and other charges, paying them off, looking up the information, and keeping it all in sync. The account system works by adding every transaction (a fine added, a payment made, a rental charge, etc.) to the "accountlines" table. Once added, this is never modified except to change certain flags (dispute and zeroed in particular.) To indicate charges being paid off, a record is added to the "accountoffsets" table that links a payment transaction to a charge transaction, along with the amount that payment contributes to the charge. If a payment is completely consumed, or a charge completely paid off, the 'zeroed' flag on that transaction is set. This is purely to save time when looking for outstanding charges or payments. Additionally to this, an "accounttotals" table is maintained that tracks the total outstanding. This is the difference between the payments put in and the charges added. It is used simply to get a quick lookup of how much a borrower owes or is in credit. This structure is intended to allow partial payments in particular, but also allows flexibility that will make other things possible, such as tracking what a particular payment is for and providing a clear audit trail of what has happened. FUNCTIONS charge_borrower $trans_num = charge_borrower($borrowernumber, $itemnumber, $amount, $type, $description, $user) This is the fundamental function for charging a borrower for something. It will add a record to the accountlines table. If the person is in credit, it may also apply that credit to this charge, if allowed to by the rules for this charge type. If this relates to an item, say a rental or fine, that should go into $itemnumber. $type is a text flag that indicates what this charge is for: N: New card F: Fine A: Account management L: Lost item R: Rental M: Sundry (anything else) $user should be the user ID that applied the charge, to aid in auditing. It may also be a text string if an ID doesn't make sense (e.g. cron jobs.) In general, this function will be called by something else that handles setting up the specifics but may be called directly if that's all you need. RETURNS The transaction number of the newly created transaction. add_payment ($trans_num, $credit) = add_payment($borrowernumber, $amount, $type, $description, $user, @transactions) This adds a payment for a borrower, indicating that they've given you money. $type is a text flag that indicates the nature of the payment. Currently this is only 'C' for 'credit'. $description is a human-readable description of the payment. $user is the borrower ID of the person putting through this payment, to aid in auditing. It may also be a text string if an ID doesn't make sense (e.g. cron jobs.) @transactions is a list of transactions that this payment will be used to pay off. It will pay off as many of these as it can. If there is money in the payment left over, then it will be credit for the user. It will not automatically pay off other charges. Often this will be called by another accounts function that handles adjusting other values in the system, but it may be called directly for simple cases. NOTES The $amount value is the amount that is being paid off. It should be a positive value, but will be converted to a negative value when written to the database. RETURNS If called in a scalar context, this returns the transaction number for the added payment. If called in a list context it returns that, and the amount of credit left over from this payment. should_use_credit_for should_use_credit_for($type) If the type of the charge is one that the system preferences say should be paid off using credit, then we say so by returning true. pay_from_credit $credit_left = pay_from_credit($transaction_number, $borrowernumber) This takes a particular transaction (that should be a charge), finds all the unused payments in the system for the borrower, and pays off this transaction using them, or as close to that as possible. Note: at the moment, $borrowernumber should be the same as the borrower that accrued the charge. RETURNS The amount of credit left for this borrower. pay $money_left = pay($charge_number, $payment_number) This links a charge to a payment, paying off some or all of the charge. It does this by writing an entry to the accountoffsets table that links them together. This doesn't support using just part of the payment, that's hopefully not going to happen. The exception to this is if the payment was part used earlier, or if the payment is larger than the charge. So really I'm just saying that it doesn't let you specify the amount. $charge_number and $payment_number may be scalars or arrayrefs (or a mix.) If they are arrayrefs, this will use each payment to pay of as much of the charges as it can, basically what you'd expect. Every charge that is paid off, or payment that is used up, will get its "zeroed" flag set to true. This will update the totals table also. RETURNS The amount of the payment(s) left over (from the provided list of payments only), or zero if it was all used up. get_transaction_info ($outstanding, $borrowernumber, $amount, $transactionnumber) = get_transaction_info($transaction_number) This gets information about a transaction, and returns either a scalar with just the amount outstanding on it, or a list containing: amount outstanding, borrowernumber, amount, transactionnumber. get_transactions @transactions = get_transactions(%filter_rules) This gets a list of transactions that match the supplied filter rules. The rules implmented are: "borrowernumber": restrict to a particular borrower number "zeroed": 0/1 - restrict to a particular zeroed status "paymentonly": if 1, this will restrict to entries that are only payment types. RETURNS A list of hashes that contain the database fields from the accountlines table. update_users_balance update_users_balance($borrowernumber, $adjustment) This updates a user's balance in the 'totals' table. $borrowernumber is the number of the borrower, $adjustment is the amount to change the total by. Keep in mind that we are tracking debt, so if they incur a fine, then it should be adjusted by a positive amount, and if they make a payment it should be negative. This is internal and not exported. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

4 4

Patch approval workflow
by Tomas Cohen Arazi 31 Mar '11

31 Mar '11

I've been digging trough the wiki, and couldn't find a list of people who are in charge of signing-off patches. Can anyone on the list point me to a place where I can find that info? To+

6 9

Re: [Koha-devel] [Koha] overdues with fines
by Chris Cormack 31 Mar '11

31 Mar '11

Heya Nicole Dont know the answer but I have cced the devel list so more developers will see it. A lot have the main list on digest so for development questions, of which documentation of features most certainly is, the devel list will get you a better hit rate. Chris Nicole Engard <nengard(a)gmail.com> wrote: >I've asked before - but got no answer. Anyone know what this report is >for? Overdues with Fines? > >It's a blank section in the manual: >http://koha-community.org/documentation/3-4-manual-en/?ch=x8286#overduesfin… > >Nicole >_______________________________________________ >Koha mailing list http://koha-community.org >Koha(a)lists.katipo.co.nz >http://lists.katipo.co.nz/mailman/listinfo/koha

2 1

Re: [Koha-devel] Error in biblio.pm
by Paul 30 Mar '11

30 Mar '11

Following up to Pete's post below (at least on a temp basis), for some of the lessons learned: a) We tried yesterday to set up a new data framework primarily for data input. Pete deleted the 999$ (well intentioned error - it is only "internal" and in hindsight should not be an option to delete within a framework) and immediately had second thoughts, reinstated it and set up the subfields over again. WRONG... this had far reaching consequences. Is it a bug to even be able to delete it if it is so intrinsic to the guts of Koha? b) At that point we started trial import of a couple of books - these created the error messages that started this thread. HOWEVER... the process wrote partial|corrupted data to SQL without any warning whatsoever - in other words the error message appeared part way through writing to SQL. Surely this is also a bug (but I'm not too sure of how to go about wring one up.) We have now had to go manually into the SQL db and remove these records. An added difficulty was that we had to "eyeball" the db, as all Koha (zebra) searches were no longer functional. Then run misc/batchRebuildBiblioTables.pl, then rebuild zebra, etc and we're back in business. All is now working as expected - search functions and staff input. c) "Koha to MARC Mapping" has a very oddball quirk. Having started with 3 errors in "MARC Bibliographic framework test": - homebranch NOT mapped the items.homebranch field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have authorised value=branches - holdingbranch NOT mapped the items.holdingbranch field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have authorised value=branches - biblio and biblionumber The biblio.biblionumber and biblioitems.biblioitemnumber fields be mapped to a MARC subfield, we remapped (again - for the umpteenth time) 999$c and $d, but they appear in all three tabs "Biblio", "BiblioItems" and "Items" and every time you edit them in one tab, they disappear from the other two as if unmapped. The end result (or at least where we're at now), is that the biblionumber must ONLY be mapped in the Biblio tab, BiblioItemnumber in BiblioItem tab and ItemNumber in Item tab DESPITE the possibility of doing otherwise - which crashes the "Search" capability .... .... and we've still got the third error in the "Framework Test" despite the system working [apparently] well (the "branches" error has automagically disappeared.) Thoughts? I still don't know why 999 is editable. What *desirable* features can be turned on and off? We have only seen a very time-consuming downside. Best - Paul Tired old sys-admin At 12:41 PM 3/30/2011 -0400, pete huerter wrote: >Yes, I had deleted 999 from our (custom) ACS Books framework, but >nowhere else. Is it possible that that could change the "Koha to MARC >Mapping", or any of the other frameworks (like default?) > >I just noticed that 999.c,d where missing entirely from our "Koha to >MARC Mapping", and (I think) this was causing all sorts of errors >(adding a biblio fails, searching, ..). I've since added them, and >run BatchRebuildBiblioTables.pl. > >It seems that we have some bad records that were added yesterday under >our ACS Books framework (that did not have 999.c,d set up properly.) >I'm thinking of just deleting these because they cause errors in >BatchRebuildBiblioTables, and batchRepairMissingBiblionumbers.pl >(http://permalink.gmane.org/gmane.education.libraries.koha.devel/5569) > >It seems like 999c,d are integral to the functioning of Koha. > >Thanks, >Pete. > >On Tue, Mar 29, 2011 at 5:14 PM, Chris Cormack <chris(a)bigballofwax.co.nz> >wrote: > > On 30 March 2011 10:06, Paul <paul.a(a)aandc.org> wrote: > >> I would appreciate some assistance with biblionumber and biblioitemnumber, > >> given that we can no longer enter new biblios. > >> > >> Error code is : "Tag "" is not a valid tag. at > >> /usr/share/koha/lib/C4/Biblio.pm line 2848" > >> > >> That line (under the head : "Internal function to add or update > biblionumber > >> and biblioitemnumber to > >> the MARC XML" is the first of these four: > >> > >> my $new_field = MARC::Field->new( > >> $biblio_tag, '', '', > >> "$biblio_subfield" => $biblionumber, > >> "$biblioitem_subfield" => $biblioitemnumber > >> > >> What are the values that biblio.pm is expecting, and where exactly are > they > >> input from GUI page > >> > <http://koha-admin/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&z395…> > >> ? > >> > >> It seems that the call is based upon biblionumber=0 [which is <10, > therefore > >> creating the error according line 2847 : "# biblionumber & > biblioitemnumber > >> are in the same field (can't be <10 as fields <10 have only 1 value)"] and > >> seeing as we are using a custom framework (cut down to what we need for > >> cataloguing staff purposes), I need to know what particular line I > have set > >> to "ignore" that is creating the error. What "Tag" have I left out? > >> > >> Can't find anything in the docs on this "Internal function." > >> > >> Thanks for any pointers, > > > > Hi Paul > > > > Have you messed around with the 999 field and subfields? Specifically > > breaking their mappings or deleting them entirely? > > > > Chris > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel(a)lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ > > git : http://git.koha-community.org/ > > bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>

1 0

Error in biblio.pm
by Paul 30 Mar '11

30 Mar '11

I would appreciate some assistance with biblionumber and biblioitemnumber, given that we can no longer enter new biblios. Error code is : "Tag "" is not a valid tag. at /usr/share/koha/lib/C4/Biblio.pm line 2848" That line (under the head : "Internal function to add or update biblionumber and biblioitemnumber to the MARC XML" is the first of these four: my $new_field = MARC::Field->new( $biblio_tag, '', '', "$biblio_subfield" => $biblionumber, "$biblioitem_subfield" => $biblioitemnumber What are the values that biblio.pm is expecting, and where exactly are they input from GUI page <http://koha-admin/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&z395…> ? It seems that the call is based upon biblionumber=0 [which is <10, therefore creating the error according line 2847 : "# biblionumber & biblioitemnumber are in the same field (can't be <10 as fields <10 have only 1 value)"] and seeing as we are using a custom framework (cut down to what we need for cataloguing staff purposes), I need to know what particular line I have set to "ignore" that is creating the error. What "Tag" have I left out? Can't find anything in the docs on this "Internal function." Thanks for any pointers, Paul tired old sys-admin. --- Archives and Collections (ACS) Society

3 2

Poll: 952i for stocknumber or inventorynumber?
by Marcel de Rooy 30 Mar '11

30 Mar '11

Hi all, Please see: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5839 and Katrin's patches. Would you prefer stocknumber as an item attribute, or inventory number? Thanks for responding! Marcel

2 1