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

Error deleting an authority
by Paul 03 Apr '11

03 Apr '11

I'm getting error: Undefined subroutine &C4::AuthoritiesMarc::prepare called at /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720. Here's the code from AuthoritiesMarc.pm ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef); 720=> my $sth = prepare("DELETE FROM auth_header WHERE authid=?"); $sth->execute($authid); The authid is being passed [correctly?] as a 4 digit integer|string: <http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&am…> Any thoughts? Thanks Paul Tired old sys-admin

3 3

700 and frameworks
by Paul 02 Apr '11

02 Apr '11

Does anyone know if Marc field 700 has any obscure dependencies in Koha that would give, when trying to save a biblio record, the error: " * Field 700 is mandatory, at least one of its subfields must be filled" despite none of the subfields being set to mandatory. The error appears to come from one of the scripts loaded in the workstation GUI because clicking "Save" does not even attempt to access the server (this from Apache2 logs.) We have a new framework that is based on "Default". Following a thread (specifically Fri, 1 Apr 2011 10:26:38 +0800) on the Koha users' list concerning frameworks, to expand the GUI presentation of Fields with multiple sub-fields, we had set the *field* to mandatory for 020, 040, 082, 100, 245, 250, 260, 300, 520, 521, 650, 700 and 942. *Only* 700 poses a problem - I have had to set it back to non-mandatory in order to save the record. Others that are set to mandatory at field level save perfectly with no input (e.g. 020 "ISBN Number" can be left blank) unless of course there is a mandatory sub-field. Is there any [easy] way to set $subfield_data{visibility} (add-biblio.pm line 346 to 351) to "" except by setting field to mandatory (or by adding valid data through Z39.50)? I have not [quickly] found another method to ensure immediate sub-field visibility in the GUI (which staff and volunteers are asking for.) Thoughts anyone? Thanks Paul Tired old sys-admin

1 0

Specifying Email headers per Notice
by Ian Walls 01 Apr '11

01 Apr '11

Fellow Developers, I've had a development request to allow librarians, on a per-Notice level, to specify the Reply-To address for each message going out. The goal is to have conversations around certain kinds of notices to be with certain staff members (for Holds, talk to this person, for Purchase Suggestions, that person...) However, specifying an email address at the Notices level would not work in a multi-branch environment; it would require that each branch configure their own copy of a Notice if they wanted their own Reply-To address. This could get messy quick. So, I ask, what's the best way to solve this issue? Should it be to tie Notices to specific branches, adding a column in the database and a filter on that column in the Notices interface? Or perhaps add an additional "Notices Reply-to Emails" configuration section in the Branch admin screen? Thank you in advance for your feedback, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

2 1

Does Koha support anything other than MySQL? We have standardized on Oracle and SQL Server.
by Hartman, David W. - GBTS Library 01 Apr '11

01 Apr '11

Does Koha support anything other than MySQL? We have standardized on Oracle and SQL Server.

2 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