July 2014 - Koha-bugs - lists.koha-community.org

[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 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 10231] New: When logging in with database user library selection is not saved
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '15

18 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10231 Bug ID: 10231 Summary: When logging in with database user library selection is not saved Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: gmcharlt(a)gmail.com To test: 1) Log into Koha with your database user, make sure you select a specific library from the pull down on the login page 2) Verify you are logged in correctly, but the top menu shows NO LIBRARY SET. We should either not show the pull down or make it work correctly. See also behaviour after applying patch 10054. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 7520] New: json script to return item types
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '15

18 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7520 Bug #: 7520 Summary: json script to return item types Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha.sekjal(a)gmail.com Small script to return list of available item types, useful for building item type lists in custom code, eg provided in sysprefs -- 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 18

[Bug 8926] New: deletedborrowers should have a timestamp
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '15

18 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8926 Priority: P5 - low Change sponsored?: --- Bug ID: 8926 Assignee: gmcharlt(a)gmail.com Summary: deletedborrowers should have a timestamp Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Database Product: Koha Most of the deleted* tables have a timestamp so you can find things deleted in a timeframe, but deletedborrowers doesn't have that. It should. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 11847] New: Display basketgroup closed date at OPAC
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '15

17 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11847 Bug ID: 11847 Summary: Display basketgroup closed date at OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 11169, 11708 Display basketgroup closed date at OPAC under "Acquisition Details" tab, on detail page. -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 11160] New: Better message when placing hold at OPAC is blocked
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '15

17 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11160 Bug ID: 11160 Summary: Better message when placing hold at OPAC is blocked 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: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an OPAC user is in a category where placing hold is blocked on all itemtypes and all libraries, the actual message when placing hold will be : "Sorry, none of these items can be placed on hold." It would be better to tell the user he can not place hold. And even not show the hold links and icons. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3