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

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

10 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

[Bug 15160] New: GetTopIssues.t should create random data
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15160 Bug ID: 15160 Summary: GetTopIssues.t should create random data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: tomascohen(a)gmail.com QA Contact: gmcharlt(a)gmail.com GetTopIssues.t currently creates fixed-value objects on the DB. If the id's it tries to use already exist on the DB it would fail. TestBuilder should take care of that. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 12363] New: Marking an item as lost in koha always returns it, but longoverdue.pl may not
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12363 Bug ID: 12363 Summary: Marking an item as lost in koha always returns it, but longoverdue.pl may not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The cronjob script longoverdue.pl has a switch --mark-returned which controls if an item is returned when marked as lost. As such, by default items are *not* returned when lost by longoverdue.pl, and at the same time, *are* returned when marked as lost from the staff intranet. In the past, marking an item as lost from additem.pl would not return the item, but doing so from moredetail.pl, so librarians had at least some control over having and item returned when lost. An update to additem.pl now causes all ways to mark an item as lost from the staff intranet. This behavior makes little sense. The flag behavior should be moved to a system preference. An upgrade path is problematic though. We could have longoverdue.pl set the system preference value based on the --marked-returned flag on each run. That would allow upgrades to work without intervention. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12812] New: Longoverdue.pl --mark-returned doesn't return items
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12812 Bug ID: 12812 Summary: Longoverdue.pl --mark-returned doesn't return items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: kyle.m.hall(a)gmail.com When testing bug 12467 I foudn that the --mark-returned flag didn't return the items as it was supposed to. The items got marked lost, but remained on the patron's account. -- You are receiving this mail because: You are watching all bug changes.

1 4