August 2015 - Koha-bugs - lists.koha-community.org

[Bug 14702] New: Fix GetReserveFee
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14702 Bug ID: 14702 Summary: Fix GetReserveFee Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com While working on bug 9809, I discovered some wonderful errors in GetReserveFee and its various calls. Bug 9809 makes just a small change in this respect; this report should do the rest :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 14602] New: Fix failing t/Creators.t test
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14602 Bug ID: 14602 Summary: Fix failing t/Creators.t test Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mtj(a)kohaaloha.com QA Contact: gmcharlt(a)gmail.com more info to come -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 6499] New: OCLC # Indexing & Matching
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6499 Bug #: 6499 Summary: OCLC # Indexing & Matching Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com I know that anyone can add indexes and matching rules, but recently we have gotten many more libraries asking for indexes and matching rules on OCLC number (Marc21 035). This enhancement request is me asking if we could get these added in as defaults. -- 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 37

[Bug 11194] New: Add a new index for edition of a document
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11194 Bug ID: 11194 Summary: Add a new index for edition of a document Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org Edition of a document (205 in UNIMARC) could be indexed in a specific index. "Edition" index exists in bib1 for this purpose, but is not used in Koha M. Saby -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 14651] New: Koha::Item::effective_itemtype should fallback to biblio-level if no item-level itemtype
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14651 Bug ID: 14651 Summary: Koha::Item::effective_itemtype should fallback to biblio-level if no item-level itemtype Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I fill this bug to start a conversation about this issue. It seems the codebase has several ways of determining the itemtype. For example, C4::Circulation::AddReturn used the biblio-level itemtype (until bug 14598) and C4::Circulation::CanBookBeIssued just sticks to item-level itemtype. At first sight, it seems clear to me that we should start moving into using Koha::Item objects, that even provide an ->effective_itemtype method! Having talked about this on IRC there seems to be a consensus that if the item doesn't have an itemtype, then there should be a fallback to biblio-level itemtype. This means we should add that check to the ->effective_itemtype method. But it would mean including Koha::Biblios. Thoughts? -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 14526] New: MoveReserve should look at future holds too
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14526 Bug ID: 14526 Summary: MoveReserve should look at future holds too Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com MoveReserve is called when checking out a book (AddIssue). When filling a hold, it moves a reserve to old_reserves (with ModReserveFill). But if the hold is a future one (say tomorrow), and it is confirmed today and waiting for pickup, and the patron comes a day sooner, it should be moved too when checking out. Small patch forthcoming. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 9593] New: Prices not imported correctly from a staged file
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9593 Bug ID: 9593 Summary: Prices not imported correctly from a staged file Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr Created attachment 15269 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15269&action=edit Prices not imported correctly from a staged file When importing a record from a staged file, sometimes, the price is set to 0 in the Vendor price field (Accounting details block) even if initially present. it occurs when the price is written without decimals : example : 19 EUR. In this case it's not captured by the regular expression in MungeMarcPrice routine (Biblio.pm) : ( $price ) = $price =~ m/([\d\,\.]+[[\,\.]\d\d]?)/; Same thing if the currency symbol was used after the digits, the result would be the same because of this : $price = $parts[1]; If I got it well, seems that the whole routine can be replaced by 2 regular expressions (may be we could even go up to a single one) integrated in GetMarcprice : the first part (symbol treatment) is unusefull as it can be treated directly by the regular expression that's following it. The part concerning groups of more than 2 digits ( if I got it, it 's come out to delete the eventual separator between thousands and hundreds) can be replaced by another regular expression. Test Plan : 1) get on your pc, the joined example file (testfile.elc). That's the kind of file most currently used in France for our acquisitions. Most of the prices in it match the pattern '[digit][digit] EUR' except 2 titles out of them : La méthodologie appliquée du commentaire de texte (14,20 EUR) Le tournant artiste de la littérature française (54,80 EUR) 2) Go to Tools/Stage MARC records for import and stage it in koha. 3) Go to Acquisition module, and an open basket of your choice and click on 'From a staged file' 4) Choose testfile.elc and add it to the basket 5) Click on the first individual 'add order' link : the price might beeing set to 00.00 in the 'Vendor price' field of Accounting details block. 6) Now go back with go back function of your browser : 7) Apply the patch 8) Click again on the same link 9) The price is now present (I hope so) 10 Sign off (I hope so again) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 105

[Bug 7957] New: Routing lists: manage several routing list for each subscription, and export them as CSV
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7957 Priority: P5 - low Change sponsored?: Sponsored Bug ID: 7957 Assignee: julian.maurice(a)biblibre.com Summary: Routing lists: manage several routing list for each subscription, and export them as CSV QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: julian.maurice(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Serials Product: Koha This development will allow to create more than one routing list for each subscription. There will be a new page for managing them (create, edit, delete), printing them, and exporting them as CSV. -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 14539] New: castToObject(), aka. make a Koha::Object from various input types
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14539 Bug ID: 14539 Summary: castToObject(), aka. make a Koha::Object from various input types Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Currently Koha is like an archeological dig site, we have different layers of dealing with various business objects. We started with DBI and numerous ways of passing an HASH around. There is no telling if it will be a List of column => values, or a reference to HASH, or a HASH or just any of the business object's (eg. Borrower's) unique identifiers (userid, cardnumber, borrowernumber). Then DBIx came to the rescue and now we are need to learn DBI and DBIx and SQL to do DB operatons in Koha. Migration to DBIx is on the way. Finally we have Koha::Object and subclasses, which include and use the DBIx, but those are not directly compatible, since Koha::Object is not a subclass of DBIx::Class making life occasionally miserable. Now we need to know 3 methods of DB accession. I am really frustrated with all of those different layers of history, and making things work nicely across all different programming patterns, I have had great success in using a casting system, where we take any value and try to make a Koha::Object-subclass out of it. So we try to cast a Scalar or a reference of Koha::Object-implementation or DBIx::ResultSet or HASH, to the desired Koha::Object-implementation. This is a nice validation/entry function in any subroutine dealing with business objects, making sure that we always have the "correct" implementation of the same business object. An example: #Does this look familiar? my $borrower = 1042; #A borrowernumber? my $user = '121A0321312'; #A cardnumber? or userid? my $borrower = {borrowernumber => 1043, cardnumber => '121A0321312', ...}; #HASH my $borrower = Koha::Borrowers->find({borrowernumber => 1024}); my $borrower = $schema->resultset('Borrower')->find({borrowernumber => 1024}); #So when I call my subroutine with the $borrower I got using some function, makeBorrowerHappy($borrower); #Bad things most often happen. #But if my makeBorrowerHappy()-function would cast its parameters to the #correct type, there would be only merriment and fun! sub makeBorrowerHappy { my ($borrower) = @_; $borrower = Koha::Borrowers::castToBorrower($borrower); ... #Do fun stuff! } #Whatever we throw at the subroutine, things just work (in theory)! Even better, if the $borrower already is a DBIx-derivative or Koha::Borrower, we don't even do anything, other than simple if statements. So minimally expensive, maximally productive. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 14012] New: Koha::FTP, a happy FTP-library to supercharge FTP operations.
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14012 Bug ID: 14012 Summary: Koha::FTP, a happy FTP-library to supercharge FTP operations. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org When dealing with FTP-connections, we need to prepare for all kinds of remote connection failures. This library simply wraps exception handling and connection creation into a one nice package. -- You are receiving this mail because: You are watching all bug changes.

1 4