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

[Bug 10476] New: Guarantor Search Not Limiting by Category Type
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '15

21 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10476 Bug ID: 10476 Summary: Guarantor Search Not Limiting by Category Type Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, the guarantor search is not being limited by category type. In guarantor_search.pl, there is code that says the search of the borrowers table should be limited by the category_type "A" (i.e. Adult) (or "I" (i.e. Institution) in the event that the patron being guaranteed has a category_type of "P" (i.e. Professional). Here is the code: my $search_category = 'A'; if ($category_type eq 'P'){ $search_category = 'I'; } $results = Search({''=>$member, category_type=>$search_category},$orderby); However! If you investigate the "Search" sub and the subsequent "SearchInTable" sub, there is no reference to the "categories" table where the "category_type" column is located. Moreover, if you actually do a search for guarantors, you will always be able to retrieve any patron. That means that professionals can guarantee professionals, and children and guarantee children. It looks like this bug was introduced when Search and SearchMember were unified into the one Search sub. -- Now...for our purposes at Prosentient...we actually want professionals to be able to guarantee professionals, so this bug is actually "beneficial". However, I imagine lots of people in public libraries might not like having a guarantor search that doesn't weed out the children. I probably won't work on this bug (at least not any time soon), but it might an idea to create a system preference that allows users to decide what type of guarantor->guarantee relationship they want to set up in terms of category types. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 12887] New: User logged out on refresh after CAS authentication
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '15

21 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12887 Bug ID: 12887 Summary: User logged out on refresh after CAS authentication Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org The user is logged out when refreshing the page directly after a CAS login. Steps to reproduce: 1) Authenticate to the OPAC through CAS. 2) Once redirected to your account, hit F5 or the refresh button of your browser. 3) You're logged out. -- You are receiving this mail because: You are watching all bug changes.

1 18

[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 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