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

[Bug 10963] New: Simplified creation of MARC21 sample frameworks
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10963 Bug ID: 10963 Summary: Simplified creation of MARC21 sample frameworks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl As mentioned on IRC, use of current sample frameworks is discouraged because they are incomplete or out of sync with default framework. I propose to build sample and fast add frameworks using default framework. New files are smaller and we need to mantain a single framework. Also there will be less strings to translate, when time comes for that. -- You are receiving this mail because: You are watching all bug changes.

1 100

[Bug 7369] New: duplicate item
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7369 Bug #: 7369 Summary: duplicate item Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com It would be nice when coming back to a bib record with items on it already to be able to choose an item to duplicate. You can duplicate bib records and subscriptions under their edit menus, but the only way to duplicate an item is to use add and duplicate which is only done when adding a new item - but often you want to duplicate an existing item at a later date and this would allow that. -- 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 45

[Bug 10933] New: PurgeSearchHistory should be merge into the C4::Search::History module
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10933 Bug ID: 10933 Summary: PurgeSearchHistory should be merge into the C4::Search::History 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 -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 13962] New: Add vendor to new acq tab in staff client
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13962 Bug ID: 13962 Summary: Add vendor to new acq tab in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using AcquisitionDetails a new tab is shown on the staff client detail page that shows order information from the acquisition module. Feedback at our user meeting was, that it would be nice to see the vendor for the orders there as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 7895] New: Add Plack/FastCGI/mod_perl server configuration and Zebra info to about
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7895 Priority: P5 - low Change sponsored?: --- Bug ID: 7895 Assignee: nengard(a)gmail.com Summary: Add Plack/FastCGI/mod_perl server configuration and Zebra info to about QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: dpavlin(a)rot13.org Hardware: All Status: NEW Version: rel_3_6 Component: About Product: Koha -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 14420] New: bulkmarcimport.pl - Some problems
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14420 Bug ID: 14420 Summary: bulkmarcimport.pl - Some problems Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: vfernandes(a)keep.pt QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz PROBLEM 1 If a record as some than one ISBN, the values are recorded in database like 'isbn1 | isbn2 | isbn3'. In the script the ISBN match are only checking for exact ISBN matching. my $sth_isbn = $dbh->prepare("SELECT biblionumber,biblioitemnumber FROM biblioitems WHERE isbn=? OR isbn like ? OR isbn like ? OR isbn like ?"); The script should verify if the ISBN is a exact match or if it appears in start, in the middle or in the end of the database isbn column: my $sth_isbn = $dbh->prepare("SELECT biblionumber,biblioitemnumber FROM biblioitems WHERE isbn=? OR isbn like ? OR isbn like ? OR isbn like ?"); The query execution should also be changed: $sth_isbn->execute($isbn, $isbn." | %", "% | ".$isbn, "% | ".$isbn." | %"); PROBLEM 2 The ISBN is not being saved in the variable $isbn because of the following line: my $isbn = $field && $field->subfield('a'); The "my" before the variable should be removed. PROBLEM 3 The $biblionumber and $biblioitemnumber are being lost after the record modification in the case of being a duplicate record. ModBiblio returns 1 if everything works right in the record modification. The following line code should be modified: eval { ( $biblionumber, $biblioitemnumber ) = ModBiblio( $record, $biblionumber, GetFrameworkCode($biblionumber) ) }; The result should be: eval { ModBiblio( $record, $biblionumber, GetFrameworkCode($biblionumber) ) }; PROBLEM 4 When modifying a record, maybe we want to append the items to the existing record. So we should pass a clone of the record to the method ModBiblio, because that method strips all items in the record. This should be done with a new argument. -updateadditems The line: eval { ModBiblio( $record, $biblionumber, GetFrameworkCode($biblionumber) ) }; Is changed to: my $clone = $updateadditems ? $record->clone() : $record; eval { ModBiblio( $clone, $biblionumber, GetFrameworkCode($biblionumber) ) }; -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 11122] New: publisher code and publication year not fetched in acq orders
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11122 Bug ID: 11122 Summary: publisher code and publication year not fetched in acq orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In acquisition, several templates try to display publisher code and publication year : invoice.tt, parcel.tt, transferorder.tt. Thoses pages use C4::Acquisition methods GetPendingOrders or GetInvoiceDetails. The bug is that in the SQL query of those methods, biblioitems.publishercode and biblioitems.publicationyear. In uncertainprice.pl those datas are fetch using GetBiblioData. It whould be better to fetch them in GetPendingOrders and GetInvoiceDetails. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 14620] New: Contact information validations
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14620 Bug ID: 14620 Summary: Contact information validations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I'm thinking we should centralize all patron's contact information validators into one module. Currently we only have validations for e-mail addresses, using the Email::Valid module. In our local library we also want to validate phone numbers with a regex that only recognizes phone numbers from my country. So I suggest we create a phone number validation as well, with an option to easily create custom regex for your local use. If a library does not wish to use validations, we should give them an option to turn them off. If more local validators are implemented, we should also give the library an option to select which validator they wish to use. With this method we could implement phone number validators from around the world and add them into our module. Then we would make the validations simply by calling our validator. The validator would know by system preference which one of the implemented phone number validators it should use. Validations should be both client and server side. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 14590] New: Checkboxes should be disabled without valid contact information in messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14590 Bug ID: 14590 Summary: Checkboxes should be disabled without valid contact information in messaging preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, in Patron message preferences, it is possible to set message transport type without valid contact information (e.g. send sms even if patron does not have a phone number set). This is very problematic for us since we have several Borrowers with misconfigured messaging preferences, and that causes issues, like Borrowers not knowing they have Items waiting for pickup. This makes customers angry and our librarians sad, not to mention the technical staff. Reasons for this are myriad but one big challenge is misconfigured messaging preferences, both in OPAC and the staff client. I have listed messaging preferences that would need to require valid contact information: #1 SMS (this requires valid SMSnumber) #2 Phone (this requires valid phone) #3 Email (this requires valid email) Validations will be done both client-side and server-side. I am working on the following plan: Server-side validation - In C4::Form::MessagingPreferences::handle_form_action(), check for each parameter (SMSnumber, phone, email) to see if they are provided. - If the parameter is provided, allow message_transport_types to contain said transport method for this message. - If the parameter is not provided, remove the said transport method for this message from message_transport_types. Client-side validation - Has to be done in both OPAC and staff client. - With JavaScript, check the contents of each contact field (SMSnumber, phone, email). - If the contact field is invalid or empty, remove all checks from messaging preferences checkboxes for this transport type. Also disable these checkboxes. - Once the contact field becomes valid on input event, enable checkboxes for this transport type and restore any previously stored state (e.g. we just want to change phone number without setting all messaging preferences again). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 12599] New: IndependentBranches Holes
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12599 Bug ID: 12599 Summary: IndependentBranches Holes 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 QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When IndependentBranches is turned on, you cannot find patrons from other branches using the search interface. However, you can change the argument for the "member" parameter, and access patrons from other branches in this way. That said, you still can't "Edit" or "Delete" patrons from other branches. "Edit" will kick you out of the record and return you to the search screen, while "Delete" tells you that you're being naughty. However... You "can": 1) change their password 2) print summaries 3) renew their registration 4) set permissions 5) export today's checked out barcodes 6) manage fines 7) check things out to them (from the Checkout tab and possibly if there is a perm/preference for checking things out to people from different branches...) 8) view circulation history && statistics 9) view purchase suggestions (and fill out the form...although saving it doesn't appear to do anything) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4