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

[Bug 12840] New: The budgeted cost and the total should not be manually modified
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12840 Bug ID: 12840 Summary: The budgeted cost and the total should not be manually modified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 12943] New: Add patron branchcode to patron search results for holds
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12943 Bug ID: 12943 Summary: Add patron branchcode to patron search results for holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 For some libraries, the current information specified in the patron results when search for a patron to place hold is insufficient. These libraries would like the branchcode to be added to the results to help identify the correct patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 12981] New: Patron attribute type limit by patron category not working on patron entry form
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12981 Bug ID: 12981 Summary: Patron attribute type limit by patron category not working on patron entry form 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you have a patron attribute type which is limited to a particular patron category the entry field will not appear on the patron entry form. The entry field for patron attribute types which have been limited by patron category are conditionally displayed based on the patron category. An error in the page's markup results in the patron category getting misreported, thus the JavaScript which shows and hides the entry fields incorrectly hides them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 13151] New: staff marc preview not wrapping
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13151 Bug ID: 13151 Summary: staff marc preview not wrapping 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 Created attachment 32796 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32796&action=edit example marc preview in staff When you're in the staff client and click the marc preview you link you have to scroll left to right to see the whole thing because it doesn't wrap. In the OPAC it looks much cleaner. Could we use that layout in the staff client since the staff are the people who care about MARC - not the patrons. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 12830] New: Move the order-related code into its own module
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12830 Bug ID: 12830 Summary: Move the order-related code into its own module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The C4::Acquisition module should be exploded in order to add readability and maintainability to this part of the code. I propose to create a new Koha::Acquisition::Order module and to put in it the code related to the order management. -- You are receiving this mail because: You are watching all bug changes.

1 42

[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 12011] New: ReservesNeedReturns breaks 'Hold Filled' functionality
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12011 Bug ID: 12011 Summary: ReservesNeedReturns breaks 'Hold Filled' functionality Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have the system preference "ReservesNeedReturns" turned on, notices for "Holds Filled" won't be generated because the logic thinks that it has already sent one. As far as I can tell, "notificationdate" doesn't even appear to be used. That seems like it would be an excellent place to record the date that a notice was sent out... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 12010] New: ReservesNeedReturns breaks 'Hold Filled' functionality
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '14

21 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12010 Bug ID: 12010 Summary: ReservesNeedReturns breaks 'Hold Filled' functionality Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have the system preference "ReservesNeedReturns" turned on, notices for "Holds Filled" won't be generated because the logic thinks that it has already sent one. As far as I can tell, "notificationdate" doesn't even appear to be used. That seems like it would be an excellent place to record the date that a notice was sent out... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1