June 2017 - Koha-bugs - lists.koha-community.org

[Bug 18852] New: Installation is inoperative even after fresh install
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '17

11 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18852 Bug ID: 18852 Summary: Installation is inoperative even after fresh install Change sponsored?: --- Product: Koha Version: 17.05 Hardware: Macintosh OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: CJSH(a)CJSHayward.com QA Contact: testopia(a)bugs.koha-community.org As of 17.05.01, I was told there were reports of successful installations. However, I have not been able to reproduce such. I had earlier made a couple of attempts to add Koha to a multipurpose appliance, and that remains my end goal. However, when I tried to back up, I saw the same issue verbatim. What I have done today was: Download a fresh Linux Mint 18.1 ISO. Build a VirtualBox VM with the ISO, with mostly default features and with third-party addons, and also enabling auto-login, but in general intended to be a plain vanilla install. Rebooted; installed Chrome and touched /etc/sudoers, ran "aptitude update"; ran "aptitude upgrade", installed MariaDB, and rebooted again. Followed the steps, including a couple of a2enmod enablings, and created a virtual site. I was able to edit passwords in /etc/koha/.../koha-conf.xml, and enter the web setup wizard. However, I experienced identical output from the installer: at a certain point, it says: > Software error: > > DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access denied for user 'root'@'localhost' at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1492. at /usr/share/koha/lib/Koha/Database.pm line 100 For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error. I am having difficulties with MariaDB and my difficulties may be contributing to the problem. My understanding, as inherited from MySQL, is that "mysql -uroot -p", for any account that will run it, will check a password and, if you have root's password set, will let you into the MySQL root command line if and only if you type the password exactly. The behavior I have observed is that as root "mysql -uroot" does not prompt for a password, but just logs you in, and "mysql -uroot -p" prompts for a password, but will accept any password, the empty password included. However, from an unprivileged account, "mysql -uroot -p" prompts for a password, but none of the passwords I've tried have worked; I've tried and used values as set in my customized koha-conf.xml, and every single password is rejected. I believe that this command line behavior is a symptom of the same problem quoted above: permission is being denied for user 'root'@'localhost' where the action in question would be permitted for any account with UID 0 and no account with any other UID. Again, this is after the 17.05.01 release, where it was reported to me that some people have had success. The system setup shows a couple of my personal idiosyncracies, but is meant to be awfully close to a procedure of "Step 1: Create a new Linux Mint VM. Step 2: Install Koha." The behavior is the same between the fresh new VM running 17.05.01, and an "everything but the kitchen sink" multitool of an appliance. C.J.S. Hayward https://CJSHayward.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17554] New: Move GetBorrowersWithEmail to Koha::Patron
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '17

10 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17554 Bug ID: 17554 Summary: Move GetBorrowersWithEmail to Koha::Patron Change sponsored?: --- Product: Koha Version: unspecified 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 C4::Members::GetBorrowersWithEmail can be easily replaced with Koha::Patrons->search({ email => $email }); -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 17738] New: Move GetReservesFromBorrowernumber to Koha::Patron-> get_holds
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '17

10 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17738 Bug ID: 17738 Summary: Move GetReservesFromBorrowernumber to Koha::Patron->get_holds Change sponsored?: --- Product: Koha Version: unspecified 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 -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 15893] New: can not save item - 500 error message - adding non latin language to public note
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '17

09 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15893 Bug ID: 15893 Summary: can not save item - 500 error message - adding non latin language to public note Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: rania.azad(a)auis.edu.krd QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl WHen I add non latin to public note and I save my item, an error 500 mesage appears, then I need to close everything and start again! or I need to clear the cookies? is there any solution for that? -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 17840] New: Add classes to internal and public notes in checkouts table
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '17

09 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17840 Bug ID: 17840 Summary: Add classes to internal and public notes in checkouts table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In order to be able to style the internal and public notes so they stand out more, it would be good if each of them had their own class. At the moment, there seems something not quite right, as both have an empty class="". To test: 1) Add an internal and a public note to an item. 2) Check out the item. 3) Verify that both notes are shown in between title and barcode in the second column of the details table. 4) Verify there is an empty class="" in the HTML source code for each -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 18701] New: Translatability: Get rid of exposed tt directives in matching-rules.tt
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '17

06 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18701 Bug ID: 18701 Summary: Translatability: Get rid of exposed tt directives in matching-rules.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Translation for file matching-rules.tt exposes a lot of template directives. Translators should not be confronted with internal code like the following: [%% PROCESS norms_select selected_norm=\"none\" id=\"mc_1_src_c_1_n_1_norm\" "name=\"mc_1_src_c_1_n_1_norm\" %%] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 16302] New: Koha::Logger performance tests
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '17

06 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16302 Bug ID: 16302 Summary: Koha::Logger performance tests 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org This test suite proves that Koha::Logger only incurs a ~25% performance hit vs the vanilla Log::Log4perl. When the Log4perl config is defined in the %ENV, then the performance hit is only 9% This is subjective and dependant on how the Logger is deployed in code. Regardless the performance is acceptable in my opinion. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 18862] New: Some DBIx relations from issues table do not seem to work
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '17

06 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18862 Bug ID: 18862 Summary: Some DBIx relations from issues table do not seem to work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org >From report 17698: my @notes = Koha::Checkouts->search({ 'me.note' => { '!=', undef } }, { prefetch => [ 'borrower', { item => 'biblionumber' } ] }); I am having problems on the template side. I can access the item and biblio information about the issue, but not the borrower information. [Internal server error triggered by AUTOLOAD in Koha::Object.] Additionally adding 'branch' will trigger a similar error. What is different with the item relation ?? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 17615] New: LDAP Auth: regression causes attribute updates to silently fail and corrupt existing data
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '17

04 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17615 Bug ID: 17615 Summary: LDAP Auth: regression causes attribute updates to silently fail and corrupt existing data Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: oliver.bock(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org There's a regression in c74678a: when calling C4::Members::Attributes::UpdateBorrowerAttribute() the compiled attribute hash uses the member name "value" instead of "attribute". This causes silent data corruption as all updated borrower attributes are overwritten with NULL values. Best, Oliver -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 16610] New: Regression in SIP2 user password handling
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '17

03 Jul '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16610 Bug ID: 16610 Summary: Regression in SIP2 user password handling Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Previous to bug 14507, SIP2 only did internal authentication. A change to the way we check empty passwords has caused any empty password to send back a CQ of Y. Previous to that patch set, a CQ of Y would only be sent back of the patron password column was NULL. Now, an empty AD field *always* returns a CQ of Y. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19