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

Bug 6085 - For the hackfesters
by Chris Cormack 06 Apr '11

06 Apr '11

Hi All First off thanks to everyone who is signing off/testing patches and bugs, whether you are at the sprint week or not you are all doing a fantastic job. Bug 6085, can't change language in OPAC and Staff was just reported, this is currently our only blocker for 3.4.x. Could people take a look at this bug, check it exists, and fix it please. This will save me having to hunt down the commit(s) that broke it and remove them from master before release. Chris

1 0

Selenium IDE - firefox extension
by Francois Charbonnier 06 Apr '11

06 Apr '11

Hello all, I am currently working on testing bugs during the hackfest hosted by biblibre, in marseille, and I started working with the firefox extension "selenium IDE" to replay the tests i'm doing. I think it would be a good thing to attach these selenium tests to each bug we are working on. This way, it will be easier to avoid side effects when we are working on groups of developpement that affect the same features. It implies that we should always work on the same dataset (we are already working on a dataset we could use : http://git.biblibre.com/?p=data;a=summary) and that each template change will lead us to make the selenium test again. But still, i think it's a good idea for all the "testers"! What about you? What do you think? Should we all try to work with selenium tests each time we can? Thank you for your answers! -- François Charbonnier http://www.biblibre.com/ Expert en Logiciels Libres pour l'info-doc Tél: 06 17 45 57 76

2 1

authorised_values.pl
by Paul 05 Apr '11

05 Apr '11

Belay my last (below) - it would have helped if I'd saved the file in the correct directory (I default to a temp_test.) Apologies, it's the end of the day. Paul G'd evening|morning to you all, In authorised_values.pl, I have modded line 63: # my $pagesize = 20; modified to 100 Paul 4 April 2011 my $pagesize = 100; in order to get more records per page (repetitive clicking "next" was getting to me...) from line 221: my @loop_data = (); # builds value list for (my $i=$offset; $i < ($offset+$pagesize<$count?$offset+$pagesize:$count); $i++){ However, I'm still only getting 20 records per page (and arthritis in my right forefinger.) Thoughts anyone? Paul Tired old sys-admin

1 0

authorised_values.pl
by Paul 05 Apr '11

05 Apr '11

G'd evening|morning to you all, In authorised_values.pl, I have modded line 63: # my $pagesize = 20; modified to 100 Paul 4 April 2011 my $pagesize = 100; in order to get more records per page (repetitive clicking "next" was getting to me...) from line 221: my @loop_data = (); # builds value list for (my $i=$offset; $i < ($offset+$pagesize<$count?$offset+$pagesize:$count); $i++){ However, I'm still only getting 20 records per page (and arthritis in my right forefinger.) Thoughts anyone? Paul Tired old sys-admin

1 0

Deleting patrons
by Cab Vinton 03 Apr '11

03 Apr '11

Will try this query on this list as the main Koha list drew a blank ... Are there any issues related to deleting patrons that one should be aware of? I'm thinking particular of the "usual" circulation and & statistical reports that libraries run for annual reports, etc. Thank you, Cab Vinton, Director Sanbornton Public Library Sanbornton, NH

2 4

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