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

[Bug 13415] New: Prevent librarians from scanning multiple items into a single barcode field
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '15

19 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13415 Bug ID: 13415 Summary: Prevent librarians from scanning multiple items into a single barcode field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It appears that some librarians will attempt to scan items as fast as they can without checking to make sure the checkout was submitted and the page reloaded properly. This can cause multiple barcodes to be scanned into the barcode field if the person is fast enough. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[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 13132] New: Confirm report delete?
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '15

18 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13132 Bug ID: 13132 Summary: Confirm report delete? Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org In most other places in Koha, you get a confirm delete message when clicking a delete button, but in saved reports you do not have this option; you choose to delete a single report, and don't get a confirmation message -- the report is immediately deleted. It would be nice if saved reports had a confirm delete button, just to catch accidental deletes. -- You are receiving this mail because: You are watching all bug changes.

1 9

[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 13412] New: Allow configuration of auto-created authorities
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '15

17 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13412 Bug ID: 13412 Summary: Allow configuration of auto-created authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org When AutoCreateAuthorities and BiblioAddsAuthorities sysprefs are on, Koha automagically creates authority records from biblios. Currently there's no way to change what data goes into the auth record. For example, field 667a always contains the text "Machine generated authority record." and 670a contains "Work cat. ($MARCOrgCode)$999c: $bib.author, $bib.title_proper, $bib.publication_date" Perhaps a new syspref where you could enter stuff like " 667a Machine generated authority record. 670a Work cat. ($MARCOrgCode)$999c: $bib.author, $bib.title_proper, $bib.publication_date " (meaning the fields 667a and 670a get the same text as they used to; see LinkBibHeadingsToAuthorities() in C4/Biblio.pm) -- You are receiving this mail because: You are watching all bug changes.

1 1

[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

[Bug 13756] New: Holds over date
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13756 Bug ID: 13756 Summary: Holds over date 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Would like to see hold over date calculated at time of hold and recorded in the requests table with the hold. As I understand it, holds over dates are calculated when the holds over table is looked at. This is a very loose calculation, since if the value of ReservesMaxPickUpDelay is changed at any time, the holds over period changes with that, regardless of when the hold was filled. Some libraries may prefer to have that date fixed in place on the table, while others might want the fluid, on the spot calculation, so perhaps it should be an option. For me, as someone dealing with consistency and reports, a fixed date in the table is preferred. It would be great to be able to run custom reports and see those dates. It would be great to have that date show in the holds information for both item and patron screens on the staff side. It would be great to be able to print that date on the hold slips. It would be great to know that if we let patrons know how long they have to pick something up, that won't change because an adjustment is made to ReservesMaxPickUpDelay (although, how often does that happen?). My two cents. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2