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

[Bug 7673] New: New patron permissions
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7673 Priority: P5 - low Change sponsored?: --- Bug ID: 7673 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: New patron permissions 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: Patrons Product: Koha refine permissions again : # limited_item_edition Limit item modification to barcode, status and note (please note that edit_item is still required) # manage_shelves Allows to manage shelves # delete_all_items Delete all items # merge_from_shelves Allows to merge records from shelves # items_limited_batchmod Limit batch item modification to item status (please note that items_batchmod is still required) -- You are receiving this mail because: You are watching all bug changes.

1 156