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

[Bug 15167] New: Remove unused script serials/acqui-search-result.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15167 Bug ID: 15167 Summary: Remove unused script serials/acqui-search-result.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org This script does not seem to be used. It has not been updated usefully since 2006. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 15102] New: Fix capitalization for some strings on XSLT detail pages
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15102 Bug ID: 15102 Summary: Fix capitalization for some strings on XSLT detail pages 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org This applies to OPAC and staff: - Contained Works - Related Works - Media Type - Content Type - Carrier Type -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 14998] New: Remove C4::Dates from install and maintenance folder
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14998 Bug ID: 14998 Summary: Remove C4::Dates from install and maintenance folder 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: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org This patch removes C4::Dates from files: - installer/data/mysql/updatedatabase.pl - misc/maintenance/fix_accountlines_date.pl -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 14523] New: Google jackets being blocked when OPAC using HTTPS
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14523 Bug ID: 14523 Summary: Google jackets being blocked when OPAC using HTTPS Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bc(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org Google jackets are not displayed in OPAC if site is configured to server HTTPS. It looks like the google-jackets.js file is hard coded to request the content via HTTP. Most browsers will block this mixed content. Changing the google-jackets.js to "https://books.google.com" resolves the problems - and displays the image correctly. Maybe we should pass another variable to GetCoverFromIsbn() specifying if we are using HTTPS or not? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 15173] New: SubfieldsToAllowForRestrictedEditing not working properly
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15173 Bug ID: 15173 Summary: SubfieldsToAllowForRestrictedEditing not working properly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have found an issue where the system preference "SubfieldsToAllowForRestrictedEditing" is not properly restricting permissions. Based on what we are seeing, I suspect it has something to do with drop down vs. free text fields. Drop down fields are locked from editing, free text fields are not being locked properly. We are trying to disable editing on 952$2, 952$a, 952$b, 952$e, 952$h, 952$o. The first three fields (which are all drop downs) are locked properly. The last three fields (which are free text) are still editable by users with the restricted editing permission. This system preference is identical in set-up with 'SubfieldsToAllowForRestrictedBatchmod' and that system preference is working properly with the same input values. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14600] New: MySQL server has gone away
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14600 Bug ID: 14600 Summary: MySQL server has gone away Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org After introducing the Koha::Object and DBIx features: We have had serious issues with MySQL/MariaDB losing the DB connection, throwing just the cryptic "MySQL server has gone away" error, after ~5 minutes of connection inactivity. This seriously affects all daemonized Perl-processes we use with C4::Context, like the SIP2-server and Plack and the Mojolicious REST API. DBIx-layer of DB handle negotiation works fine detecting a stale connection, but the new connection generation is delegated to DBI (this is inefficient duplication). DBI-layer doesn't detect a stale connection and for us (LXC v1.03, Ubuntu 12/14.04) the "mysql_auto_reconnect"-parameter doesn't work. Our improvement targets the C4::Context->dbh(); <<SNIP if ( defined($context->{db_driver}) && $context->{db_driver} eq 'mysql' && $context->{"dbh"} ) { return $context->{"dbh"}; } elsif ( defined($context->{"dbh"}) && $context->{"dbh"}->ping() ) { return $context->{"dbh"}; } SNAP>> #This prevents the $dbh->ping() from ever getting called: if ( defined($context->{db_driver}) && $context->{db_driver} eq 'mysql' && $context->{"dbh"} ) { #because $context->{dbh} is true even if the connection is dead. #Obviously this relies on the "mysql_auto_reconnect"-parameter which doesn't #work. This patch adds a timer to ping every 4 minutes to see if the connection is still alive, regardless of the DB we use (MySQL/MariaDB vs ...). Pinging every 4 minutes shouldn't make a performance dent, but makes it possible for us to operate our SIP2-server without restarting it every 5 minutes. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 14374] New: dont use mysql_auto_reconnect with BDIx::Connector
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14374 Bug ID: 14374 Summary: dont use mysql_auto_reconnect with BDIx::Connector Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org BDIx::Connector doc indicates that handler option mysql_auto_reconnect must be false. See http://search.cpan.org/perldoc?DBIx%3A%3AConnector%3A%3ADriver%3A%3Amysql So it should not be setted in C4::Context -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 14375] New: DBIx::Connector should be stored in C4::Context instead of dbh
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14375 Bug ID: 14375 Summary: DBIx::Connector should be stored in C4::Context instead of dbh 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: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org DBIx::Connector doc about $conn->dbh() indicates he will manage database handler cache and reconnection : http://search.cpan.org/perldoc?DBIx%3A%3AConnector#dbh So C4::Context should not store dbh object but DBIx::Connector object and get handler from it. We experimented issues with SIP server, since its database connections will run all day long. Looks like DBIx::Connector manages very well the reconnection. -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 14560] New: Rameau authorities
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '15

11 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14560 Bug ID: 14560 Summary: Rameau authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The purpose of this patch is to give a clean support of the composed Rameau authorities. This has been discussed a lot in Bug 8304, and led to a Failed QA (deserved, imho). I've rewritten this from scratch, while keeping in mind to separate as much as possible the Rameau code from the legacy koha code. What are Rameau authorities? ---------------------------- Rameau authorities are composed authorities that look like this: 606 _311954119 _aGuerillas _311943195 _yBolivie _311976947 _z1945-1970 The purpose of this patch is to allow to add the koha internal links ($9) when merging the authority, while preserving the subfield order, which is meaningful. If processed correctly (with this patch), the result after merge should be: 606 _311954119 _926311 _aGuerillas _311943195 _926312 _yBolivie _311976947 _926313 _z1945-1970 _2rameau How does it work? ----------------- A new package has been introduced, C4/AuthoritiesRameau.pm, which is used only if the useRameau syspref is enabled. Unit tests are here : t/db_dependent/AuthoritiesRameau.t There are only 3 changes to the original merge code: 1) Adds a new parameter to be able to specify if we want to merge to a specific biblio. 2) Skip the legacy code if useRameau is enabled and there are multiple $9 in the field. 3) use C4/AuthoritiesRameau.pm if useRameau is enabled. Test plan --------- It might be a little problematic for you to test this, because Rameau authorities are only used in France, so you may have to forge authorities if you don't have data with Rameau authorities. (or someone from France could test it ? :)) Anyway, make a call to the merge function like this: merge($mergefrom,$MARCfrom,$mergeto,$MARCto, $biblionumber); With $mergefrom and $mergeto being the same koha authid, and $MARCfrom and $MARCto being the result of GetAuthority($authid), and $biblionumber the biblio you want to merge the authority in. I'm not sure there is a way to do this in the interface, if anyone knows... -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 10886] New: When intranetreadinghistory is set to not allow - staff can still view patron's history in item history
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10886 Bug ID: 10886 Summary: When intranetreadinghistory is set to not allow - staff can still view patron's history in item history Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: danielle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When intranetreadinghistory system preference is set to not allow, the individual patron's history can not be viewed, but if you look at the item history, staff can still view patrons who have checked out that item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15