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

[Bug 12272] New: Refactor C4::Service API into Koha::Service class
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '15

21 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12272 Bug ID: 12272 Summary: Refactor C4::Service API into Koha::Service class Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jweaver(a)bywatersolutions.com Reporter: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is intended to clean up C4::Service's API and bring a number of /svc/ scripts that do not currently use it into the fold. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 11272] New: copy submit button on inventory
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '15

21 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11272 Bug ID: 11272 Summary: copy submit button on inventory Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org On the inventory tool the submit button is a the very bottom, but it should probably be in two places. One under the file upload and one at the bottom. This will make it clear that if you do a file you don't have to fill in the filter options - just submit. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 13058] New: Deleting reports should be a permission setting, not a default
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13058 Bug ID: 13058 Summary: Deleting reports should be a permission setting, not a default Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: jendayi30(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org One of our librarians just reported to me that she accidentally deleted one of our saved reports off the system. Her permissions were only set to "Execute reports" so this scenario should not be possible. It seems to be an unintended effect of incorporating the ability to delete multiple reports (bug #3134). It would be nice to have a permissions setting for deleting reports. Either a syspref for enabling the multiple reports feature or a permissions setting for deleting reports would work. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 11151] New: hold error message wrong if in transit
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11151 Bug ID: 11151 Summary: hold error message wrong if in transit Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 22475 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=22475&action=edit error If you try to check out and item that is in transit to another branch to fill a hold the error message says: "Item 1001 ways to be romantic : (0114972293947) has been waiting for Lloyd Bonafide (1114911111119) at South Holiday since Cancel hold Revert waiting status" But the item is in transit - not waiting - I don't know what will happen if I ignore this because I'm in training right now, but I wanted a record of the fact that error message reads wrong - and probably will cause problems with transfers. See attached images. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7255] New: Information on Holds Transfer Slips is Inconsistent
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Bug #: 7255 Summary: Information on Holds Transfer Slips is Inconsistent Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com CC: ago(a)bywatersolutions.com, gmcharlt(a)gmail.com Some of my libraries are experiencing situations where the items barcode number and call number sometimes print on the hold transfer slip and sometimes not. Other libraries have never had this information print on the slip. We've discovered that they've got a race condition in the code; when you click "confirm and print slip", you're both submitting the form that confirms the hold, as well as opening the transfer slip page. If this is a title-level hold originally, the item information (barcode and callnumber) isn't filled in until the form you've submitted completes it's action. So, depending on all kinds of server-level variables, the transfer slip process will either complete first, and not show item information, or complete second, and include barcode/callnumber. There is no way to tell which process will win the race ahead of time. So that's WHY it's a problem. As to how to fix it, we're not sure yet. The best solution would be to modify the page so that submitting the form completes, then triggers the hold slip (rather than both starting up at once), but that would involve an extensive reworking of the system. A quicker solution is to introduce a delay, but we're not sure exactly where yet. -- 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 19

[Bug 12514] New: Pressing 'print and confirm hold' on check in triggers race condition
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12514 Bug ID: 12514 Summary: Pressing 'print and confirm hold' on check in triggers race condition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Library has the following set for RESERVESLIP: <p><font size="15"><<borrowers.surname>></font> </p> <p> <h5>Transfer to/Hold in <<branches.branchname>></h5> </p> <br /> <h4>ITEM ON HOLD</h4> <h3><<biblio.title>></h3> <ul> <li><<items.barcode>></li> <li><<items.itemcallnumber>></li> <li><<reserves.waitingdate>></li> <li><<reserves.expirationdate>></li> </ul> <p>Notes: <pre><<reserves.reservenotes>></pre> </p> When an item filling a hold is checked in, the circ staff clicks the 'print and confirm' button. Borrower and biblio information is printed on the slip, but item and reserve information is not. If the circ staff re-scans the barcode for the item, the confirm hold dialog boxes will re-appear; clicking 'print and confirm' a second time will print correctly, because by that time the reserves record will be populated. All holds filled at this library process slowly enough to trigger this bug. Unlike bug 11621, this is *not* an intermittent condition. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 12604] New: TestBuilder - Refactoring Category.t
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12604 Bug ID: 12604 Summary: TestBuilder - Refactoring Category.t Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: yohann.dufour(a)biblibre.com QA Contact: gmcharlt(a)gmail.com In order to see what the module TestBuilder can bring to the writing of tests, the tests in Category.t have been refactored with the use of TestBuilder. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 13322] New: Update MARC21 frameworks to Update No. 19 (October 2014)
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13322 Bug ID: 13322 Summary: Update MARC21 frameworks to Update No. 19 (October 2014) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bibliographic and authority. "Update No. 19 (October 2014) includes changes resulting from proposals that were considered by the MARC 21 community during June 2014." -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 13069] New: Enable sort by title to ignore articles on circulation and patron detail pages
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13069 Bug ID: 13069 Summary: Enable sort by title to ignore articles on circulation and patron detail pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: martin.renvoize(a)ptfs-europe.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With the conversion of the circulation and patron detail checkout summary tables to AJAX recently we lost the ability to sort by title while ignoring articles. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 13182] New: When placing an order from a staged file, check for duplicates, display availability information, choose to overlay matched records.
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '15

20 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13182 Bug ID: 13182 Summary: When placing an order from a staged file, check for duplicates, display availability information, choose to overlay matched records. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org When making acquisitions from one staged file, by many branches as a joint effort, it is important to be able to make orders from the same import_record. This places some extra requirements. 1. An status = 'imported' import_record needs to be shown in the stage_file so other branches can order from it as well. So we can't "hide" a import_record from the staged_file after an order is placed. 2. Having imported one import_record, that import_record must know it is matched to the just imported Biblio, so next acquirers know that it is already in our catalog. 3. We need to know which other branches have already ordered the item so we wont end up ordering too many copies of one Biblio to the consortium. Thus we color each row and show the count of Items in the current user's branch and the total amount of Items in the whole consortium. Additional tooltip listing of Item counts by Branch is displayed so we know are there any such Items near us. 4. If we know we already have a matching biblio in Koha, we can optionally overlay the existing Biblio with the new one. (We don't really need it but looks like Bug 12074 needs it). Also a good hook to attach more advanced automatic overlaying/transformation mechanisms. TEST PLAN: SETUP: 0a. Define a Matcher from admin/matching-rules.pl. We think good starting values are: rules, score 020a, 1000 024a, 1000 028a, 1000 245a, 500 240a, 500 110a, 300 100a, 300 Matching threshold 800 0b. Stage a MARC file. 1. Start making an order from a staged_file, stop when you see the import_records after you selected the batch to order from at acqui/addorderiso2709.pl?import_batch_id=50... 2. If you have matches, they are colored and the Item counts are visible. If not, order any item and return to the previous view and reload. 3. Observe that you should now have atleast one match. The match displays the amount of items in your branch, in your consortium, and a tooltip from the record title, showing a breakdown of items by branch. 4. When you add more orders, you get more order lines, but all orders are for the same Biblio, thus you don't get many Biblios, one per order. TODO: Unit tests. TODO: Better test plan. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19