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

[Bug 8735] New: Expire holds waiting only on days the library is open
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '14

22 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8735 Priority: P5 - low Change sponsored?: --- Bug ID: 8735 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Expire holds waiting only on days the library is open Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha There is a problem with expiring reserves. Let us say an items has two holds placed on it, and is set to waiting for the first hold. This hold is then canceled for waiting too long, yet it will remain sitting on the holds shelf until a librarian either returns it to the shelf, or sets it too waiting for the next person in line to get it. During the interim, the item will appear to be available for checkout. This is not a problem most of the time, as the holds expire late at night and the librarians will take care of it in the morning, but over a holiday weekend, it is possible that an item will remain in this state for days at a time. We can fix this situation by adding a system preference to decide of waiting holds should be canceled on holidays, or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 9177] New: Duplicate patron: Prepopulated fields ar cleared when setting cursor
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '14

22 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9177 Bug ID: 9177 Summary: Duplicate patron: Prepopulated fields ar cleared when setting cursor Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 13790 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13790&action=edit Screenshot Duplicate patron - prepopulated fields cleared How to reproduce: 1) Go to a patron's detail page 2) Click "Duplicate" 3) On the screen, click in one of the prepopulated fields, e.g. Surname or City Result: The field is cleared. Expected: Cursor is set without clearing the field. Is this a bug or is it by design? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 8214] New: Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 Priority: P5 - low Change sponsored?: --- Bug ID: 8214 Assignee: gmcharlt(a)gmail.com Summary: Create a bound with function Severity: enhancement Classification: Unclassified OS: All Reporter: steven_jeffery(a)fmi.com Hardware: All Status: NEW Version: unspecified Component: Cataloging Product: Koha There are occassionally multiple distinct monographs which are bound together. Koha currently lacks a good way to handle these items. Examples: 1. US Geological Survey Bulletins 12 and 13 are bound into one volume. Each was originally published separately, have their own OCLC records, etc. 2. Eight pamphlets on soccer are bound together. Each was published separately but were bound together. They each have separate publishers and records. The key features of this would be: * All the items would have the same barcode. * There would be some sort of item-level display indicating what it was bound with. * All the items would have the same call number. * It would not be necessary to create an additional "ghost" record to hold the sub-records. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 9700] New: Automatically remove some fields or subfield on biblio import
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9700 Bug ID: 9700 Summary: Automatically remove some fields or subfield on biblio import Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: anthony.laquerre(a)ccsr.qc.ca CC: m.de.rooy(a)rijksmuseum.nl This is a request for enhancement. When importing records, whether by Z39.50 or via Tools-Prepare MARC records to import, there is currently no possibility to tell Koha that we do not want certain fields or subfields MARC. For example, for each of the imported records, we currently remove several fields manually each time (eg 043, 263, 521, 653, etc.).. These unwanted fields can be different for each koha instance according to local policies. It is the same for certain sub-fields, we derive manually each time (eg: $ 700 e). It would be possible to save considerable time if we could configure fields and subfields rejected for import. This would avoid manually remove each record. Thanks -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 6354] New: show marc labels on a per user basis
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6354 Bug #: 6354 Summary: show marc labels on a per user basis Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com would be nice if you could choose on a per user basis if the marc labels showed in cataloging. right now it's a preference that applies to all or none ... instead each user might like to choose based on their cataloging skills. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 1

[Bug 6029] New: Date processing not done to all dates in overdue mails
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6029 Bug #: 6029 Summary: Date processing not done to all dates in overdue mails Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5992 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 6

[Bug 7398] New: Show number of holds on a biblio in the OPAC details
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7398 Bug #: 7398 Summary: Show number of holds on a biblio in the OPAC details 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: ian.walls(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com Like on the staff client, it should be possible to show the number of holds currently on a title. This will allow patrons to know how long a wait is going to be without having to log into the OPAC. Work to be done: * Add a new system preference, OPACShowHoldsCount, that will control whether the total number of holds shown on the OPAC detail page or not. Summon this syspref on the opac-detail page, and pass to the template * Add call to GetReservesfrombiblionumber. Take the holdcount return variable, and pass it to the template. * Edit opac-detail.tt to check for OPACShowHoldsCount, and if it's true, display the number of holds in a div similar to the one used staff-side * Edit the opac.css to properly and aesthetically display this new div -- 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 49

[Bug 9342] New: zebra UNIMARC dom indexing does not work
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9342 Bug ID: 9342 Summary: zebra UNIMARC dom indexing does not work Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: paul.poulain(a)biblibre.com CC: m.de.rooy(a)rijksmuseum.nl Testing bug 8984, I find that the UNIMARC dom indexing does not work. Without patch 8984, a fresh install, with UNIMARC, DOM and CHR (not ICU) result in a bad: 15:28:48-03/01 zebraidx(25369) [warn] Unknown register type: (and no indexing is made) -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 7878] New: When duplicating a patron too many fields carrying over
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7878 Priority: P5 - low Change sponsored?: --- Bug ID: 7878 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: When duplicating a patron too many fields carrying over QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Patrons Product: Koha When duplicating the patron in the top section only the Surname should carry over - right now the other name and initials carry over. Along the same lines at the bottom the expiration date is coming over and that could be different based on when you're doing the duplication and your patron category rules. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 8646] New: Certain search terms cause browser "script taking too long" error
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '14

19 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8646 Priority: P5 - low Change sponsored?: --- Bug ID: 8646 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Certain search terms cause browser "script taking too long" error Severity: minor Classification: Unclassified OS: All Reporter: robin(a)catalyst.net.nz Hardware: All Status: NEW Version: master Component: Staff Client Product: Koha Some search terms, particularly those with space characters and similar non-alpha things at the end, can cause the javascript highlighter to go into an infinite loop which causes an error in the browser. Search queries such as: http://koha-intra/cgi-bin/koha/catalogue/search.pl?kw=idx&q=ti:book%20 reproduce this. Curiously, the OPAC is unaffected by this, however it has similar code processes that mean it may be possible for this to happen there too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11