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

[Bug 9171] New: Vendor sent us a file with holdings in 952 which has repeated subfields and no home or holding branch
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9171 Bug ID: 9171 Summary: Vendor sent us a file with holdings in 952 which has repeated subfields and no home or holding branch Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: mdhafen(a)tech.washk12.org Created attachment 13785 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13785&action=edit usmarc file to demonstrate the bug Staging a file for import where the item information is in the 952 tag, but lacks home/holding branch information and may have repeated subfields, results in items with no branchcode set and near empty items for the repeated subfields To test: stage and import the attached usmarc file and note that some items, like in the first record, are missing the homebranch and holdingbranch information, and because of the repeated 'z' subfield another item record is created just for the repeated field. Apply patch and stage and import the file again to see that these items are imported correctly. I had to deal with a file from a vendor which had the holdings information in the 952 tag. This was for new books, so there was obviously no itemnumber. There was also no home or holding branch set, so the items got a little lost. To further complicate matter the 'z' subfield was repeated in a couple fields, and MARC::Record seemed to think those repeated subfields should be in a field by themselves. So I have a patch which adds code to watch for this missing home/holding branch subfields, and catches repeated subfields that end up in seperate fields. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 5408] New: Refactor C4::Circulation::GetIssuingRule
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5408 Summary: Refactor C4::Circulation::GetIssuingRule Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: cfouts(a)liblime.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 GetIssuingRule submits a cascade of queries to the database to find its match. This could be optimized and cleaned up by retrieving them all at once. -- 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 12

[Bug 5359] New: Parcel receive improvement
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5359 Summary: Parcel receive improvement Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Parcel_receive_acq _RFC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Deadline: 2011-05-01 * A control will be added if the librarian declares more recieves than what has been ordered. This will be usefull to avoir typing mistakes * We will add fields in the form to let the librarian modify budget on the fly -- 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 7

[Bug 8722] New: C4::Circulation needs unit test
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8722 Priority: P5 - low Change sponsored?: --- Bug ID: 8722 Assignee: gmcharlt(a)gmail.com Summary: C4::Circulation needs unit test Severity: enhancement Classification: Unclassified OS: All Reporter: elliott(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Test Suite Product: Koha Write unit tests for all of C4::Circulation -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 8734] New: Acquisitions- Quantity for ordering from suggestion unable to modify
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8734 Priority: P5 - low Change sponsored?: --- Bug ID: 8734 Assignee: koha-bugs(a)lists.koha-community.org Summary: Acquisitions- Quantity for ordering from suggestion unable to modify Severity: enhancement Classification: Unclassified OS: All Reporter: jsbbala(a)gmail.com Hardware: All Status: NEW Version: rel_3_6 Component: Acquisitions Product: Koha Created attachment 11997 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=11997&action=edit ordering problem In acquisition when we go for new order of a book a field is mandatory ie Quantity of the book. It is default 0(zero) we cannot change the quantity and save -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 8855] New: get from receipt to invoice
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8855 Priority: P5 - low Change sponsored?: --- Bug ID: 8855 Assignee: koha-bugs(a)lists.koha-community.org Summary: get from receipt to invoice Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha It would be nice if you could get from the receipt page to the invoice page with a click. Right now you can get to the receipt page from the invoice page, just not the other way around. I think it would just require making the invoice number a link that goes to the corresponding invoice page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 6418] New: display 590a
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6418 Bug #: 6418 Summary: display 590a Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org >From a partner: "We've added our journal holdings data to multiple 590/a fields. We'd like these to display in both the search results pages and in the individual bib record in the OPAC and the staff client. The information is displaying in the title detail tab but we don't want to have to click to it; we're used to seeing it immediately with the title information. Attache jpg shows Title Details tab with 590/a information, search results example with note where to display 590/a and bib record with note where to display 590/a" Two suggested ways to tackle this: If XSLT: The best way to display the 590a in a community-friendly way is to allow user-uploaded XSLT. This is comparatively simple, as we'd just need to code up the file upload scripting, and then point the XML parser at that XSLT instead of the built in one. It would involved writing XSLT, which is unpleasant, but we would help with that, and a page could be added to the Koha wiki to share completed XSLTs If Normal view: For this method, I'd go with teching up the Keyword to MARC mappings tool and add more supported Keywords. This would again not be 590a-specific, but rather a matter of placing the keyword tokens into the code in the right places, then configuring those keywords to map to the right MARC. "Keyword" is probably not the right term to be using here, so renaming might make things clearer for the continued use of this functionality. -- 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 5

[Bug 8326] New: allow attributes to be made repeatable
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8326 Priority: P5 - low Change sponsored?: --- Bug ID: 8326 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: allow attributes to be made repeatable Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com URL: cgi-bin/koha/admin/patron-attr-types.pl?op=edit_attrib ute_type&code=DL Hardware: All Status: NEW Version: master Component: Patrons Product: Koha I understand not letting people edit attribute codes or the fact that it's a unique identifier after it has been saved, but I see no reason why an attribute can't be made repeatable retroactively. I think this value should be editable - at least from 'not repeatable' to 'repeatable' since it might cause problems going from 'repeatable' to 'not repeatable'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 8460] New: Improve Error Handling
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8460 Priority: P5 - low Change sponsored?: --- Bug ID: 8460 Assignee: gmcharlt(a)gmail.com Summary: Improve Error Handling Severity: enhancement Classification: Unclassified OS: All Reporter: thatcher.rea(a)bywatersolutions.com Hardware: All Status: NEW Version: unspecified Component: Architecture, internals, and plumbing Product: Koha We've had a few scenarios recently when a library patron experiences a catalog error. The default messages say "For help, please send mail to the webmaster (test(a)example.com) giving this error message and the time and date of the error." 9 times out of 10, the patron will simply copy the error, and provide no additional information about the event at all. Not even what catalog they were working on, which makes these messages effectively useless. I propose that these messages be written instead to say "Please click here to send the system administrator an error report." Which can then send an internally generated message containing: * referring link * the error message * server info * koha version, etc This could be sent to the address in the KohaAdminEmailAddress sypref. Regards, :T -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 8528] New: Move C4::Calendar to Koha::Closure
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8528 Priority: P5 - low Change sponsored?: --- Bug ID: 8528 Assignee: koha-bugs(a)lists.koha-community.org Summary: Move C4::Calendar to Koha::Closure Severity: enhancement Classification: Unclassified OS: All Reporter: elliott(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Holidays Product: Koha This will be a blanket ticket for the smaller encompassing tickets for moving and cleaning up holidays. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7