May 2012 - Koha-bugs - lists.koha-community.org

[Bug 5394] New: Fatal error when searching for a non-existant item when receiving an order
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '13

24 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5394 Summary: Fatal error when searching for a non-existant item when receiving an order Change sponsored?: Sponsored Product: Koha Version: rel_3_0 Platform: All URL: http://localhost:8080/cgi-bin/koha/acqui/orderreceive. pl?supplierid=4&freight=0&invoice=2117008&receive=9781 563636783 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: mjr(a)ttllp.co.uk QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 A book is a new edition of the title in the catalogue, but their records are, and should remain, completely unrelated. I couldn't see a record for it in the acquisition module so I searched for it by ISBN from here: http://localhost:8080/cgi-bin/koha/acqui/parcel.pl?type=intra&supplierid=4&… under "search orders to add to this shipment" to check that the new edition record wasn't tucked away somewhere. I got the error message "Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/share/koha/cgi-bin/acqui/orderreceive.pl line 192." This appears to be because the end of acqui/orderreceive.pl doesn't check whether the earlier GetBookSellerFromId actually found anything. I will prepare a simple patch. I think this is 3.0.x only. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 2

[Bug 7189] New: preference to control if returning lost items gives refund
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '13

24 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7189 Bug #: 7189 Summary: preference to control if returning lost items gives refund Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com Right now when you return an item that was lost the patron's card is credited with the lost fee, but not all libraries refund lost fees and sometimes the fee is refunded after the patron has paid for it - causing all kinds of financial issues. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 37

[Bug 7919] New: Display the Codes koha according to connexion libraries
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '13

24 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7919 Priority: P5 - low Change sponsored?: --- Bug ID: 7919 Assignee: gmcharlt(a)gmail.com Summary: Display the Codes koha according to connexion libraries QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: stephane.delaye(a)biblibre.com Hardware: All Status: NEW Version: rel_3_8 Component: Cataloging Product: Koha >From Koha administration: Patron categories .. / cgi-bin / koha / admin / categorie.pl? & op = add_form CategoryCode = [^] and Authorized values / cgi-bin/koha/admin/authorised_values.pl? op = & id = add_form and Patron attribute types gi-bin/koha/admin/patron-attr-types.pl? edit_attribute_type = op & code = [^] and Item types / cgi-bin/koha/admin/itemtypes.pl? op = add_form & itemtype = link each code to a branchcode list. Then the administrator can choose to link a code (category, attribute, value allowed) to a specific branchcode Interest: each librarie will see that its codes. Each librarie will be able to secure the access and the use of its codes in a network. The filter should apply to the following screens: MEMBERS .. / cgi-bin / koha / members / members-home.pl [^] .. / cgi-bin / koha / members / memberentry.pl? op = add & CategoryCode = [^] .. / cgi-bin / koha / members / memberentry.pl? op = add & CategoryCode = [^] PERIODICAL ... / cgi-bin / koha / serials / subscription-add.pl? op = & mod = SubscriptionId ... ACQUISITIONS ... / cgi-bin / koha / admin / aqbudgets.pl? & op = add_form budget_parent_id = 131 & budget_period_id = .. ... / cgi-bin / koha / acquisition / neworderempty.pl? OrderNumber = 26 & booksellerid = 2 & basketno = ... TOOLS .. / cgi-bin / koha / tools / modborrowers.pl SORT1, SORT2, borrower_attribute, CategoryCode, branchcode ... / cgi-bin / koha / tools / batchMod.p ==> Items.location ==> Items.notforloan ==> items.ccode CATALOGUING / cgi-bin/koha/cataloguing/additem.pl? biblionumber = / cgi-bin/koha/cataloguing/addbiblio.pl? biblionumber = 37202 & op = OPAC .. / cgi-bin / koha / opac-search.pl -- You are receiving this mail because: You are watching all bug changes.

1 101

[Bug 4906] New: Problem with grace period calculation and fine intervals >1
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '13

24 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4906 Summary: Problem with grace period calculation and fine intervals >1 Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 With a fine interval > 1 there is currently no way to avoid a effective grace period. Fines can not start the day after the due date. Configuration: With grace period = 1 fine interval 5 (= weekly, the library is closed Sunday and Saturday) Result: The first fine ist set 7 days after the item was due. Monday, checkout Tuesday, item due Wednesday Thursday Friday Saturday, holiday Sunday, holiday Monday, Tuesday, first fine Grace period for fine intervals > 1 should describe the days between the due date and the day the first fine is set. CalcFines() in Overdues.pm: 266 my $days_minus_grace = $daystocharge - $data->{'firstremind'}; 267 if ($data->{'chargeperiod'} > 0 && $days_minus_grace > 0 ) { 268 $amount = int($daystocharge / $data->{'chargeperiod'}) * $data->{'fine'}; -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 38

[Bug 7387] New: Add Template::Toolkit plugin to allow caching of includes
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '13

24 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7387 Bug #: 7387 Summary: Add Template::Toolkit plugin to allow caching of includes Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: ian.walls(a)bywatersolutions.com Depends on: 929, 7248 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 26

[Bug 6314] New: UNIMARC OPAC XSL improvements
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '13

24 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6314 Bug #: 6314 Summary: UNIMARC OPAC XSL improvements Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha-community.org - Exclude 'marc' & 'item' prefix from UNIMARC util XSL to slim down result - Add missing NSB/NSE characters striping - 200 fields on result/detail page: show all subfields in order, link to detail page only on $a - 4xx display, more fields and more subfields, respects subfields order which matter - Add missing fields: 205, 500 - Add missing MARC21 syspref: - DisplayOPACiconsXSLT, not implemtable in UNIMARC - OPACURLOpenInNewWindow - URLLinkText - ShowISBD Sidenote: this should have been done by people having introduced those syspref into MARC21 XSL. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 24

[Bug 6209] New: Standardize on one javascript library for client-side form validation
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '13

23 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6209 Bug #: 6209 Summary: Standardize on one javascript library for client-side form validation Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com We handle client-side validation in a piecemeal fashion. It would simplify things for the user and developers if we standardized on one JavaScript library for handling all client-side form validation. I propose we use this one: http://bassistance.de/jquery-plugins/jquery-plugin-validation/ Syntax is pretty simple: In the JavaScript: $(document).ready(function(){ $("#commentForm").validate(); }); In the markup: <form id="commentForm" method="get" action=""> <input id="cname" name="name" size="25" class="required" minlength="2" /> "class='required'" tells the script to validate that field as required. Other options include email, url, date, number, specific length, etc. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 29

[Bug 5608] New: Tool to move MARC21 series info to 490 tag
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '13

22 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5608 Summary: Tool to move MARC21 series info to 490 tag Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Command-line Utilities AssignedTo: gmcharlt(a)gmail.com ReportedBy: mdhafen(a)tech.washk12.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 With the MARC21 standard moving from the 440 to the 490 it would be nice to have to tool that would move information in the catalogue from the 440 to the 490. I've written a tool that switches the information in the two tags for records found to have series information in the database. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 35

[Bug 5635] New: bulkmarcimport new parameters & features
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '13

22 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5635 Summary: bulkmarcimport new parameters & features Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: PATCH-Sent Component: Command-line Utilities AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 it's sometimes useful to do some changes on the fly on biblios or items. We will add a YAML file to do some mappings when running bulkmarcimport we will also add: * a test parameter * an insert parameter to allow INSERT only * and update parameter to allow biblios to be only updated * a filter on tags/subfields -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 40

[Bug 5937] New: Subtle differences in columns between installed db and upgraded db
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '13

21 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5937 Bug #: 5937 Summary: Subtle differences in columns between installed db and upgraded db Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org Mainly differences in NULL or NOT NULL; and UNI vs MUL indexes. 52c52 < aqbasketgroups.billingplace varchar(10) YES --- > aqbasketgroups.billingplace varchar(10) NO 106c106 < aqbudgets.budget_amount decimal(28,6) YES 0.000000 --- > aqbudgets.budget_amount decimal(28,6) NO 0.000000 116c116 < aqbudgets.budget_period_id int(11) YES --- > aqbudgets.budget_period_id int(11) YES MUL 200c200 < auth_subfield_structure.frameworkcode varchar(10) NO --- > auth_subfield_structure.frameworkcode varchar(10) YES 556c556 < default_circ_rules.holdallowed int(1) YES --- > default_circ_rules.holdallowed tinyint(1) YES 631c631 < deletedborrowers.cardnumber varchar(16) NO MUL --- > deletedborrowers.cardnumber varchar(16) YES MUL 660c660 < deletedborrowers.privacy int(11) NO 1 --- > deletedborrowers.privacy int(11) YES 710c710 < deleteditems.stocknumber varchar(32) YES MUL --- > deleteditems.stocknumber varchar(32) YES UNI 807c815 < issues.itemnumber int(11) YES MUL --- > issues.itemnumber int(11) YES UNI 989c997 < message_attributes.message_name varchar(40) NO UNI --- > message_attributes.message_name varchar(40) YES UNI 1352c1391 < suggestions.suggesteddate date NO 0000-00-00 --- > suggestions.suggesteddate date YES -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 2