July 2019 - Koha-bugs - lists.koha-community.org

[Bug 18587] New: LDAP: update_local is entirely untested!
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18587 Bug ID: 18587 Summary: LDAP: update_local is entirely untested! Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org, gmcharlt(a)gmail.com, hblancoca(a)gmail.com, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, mtj(a)kohaaloha.com, oliver.bock(a)aei.mpg.de, tomascohen(a)gmail.com Depends on: 14625 The update_local routine inside C4/Auth_with_ldap.pm is entirely untested :(. Reading the code, there are assumptions within it that don't hold true either. For instance, it is assumed that the routine always returns 'cardnumber', when in fact, it can return 'undef' or an integer specifying the number of rows updated by the procedure.. which should only ever be '1'. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14625 [Bug 14625] LDAP: mapped ExtendedPatronAttributes cause error when updated on authentication -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 21987] New: Local cover 'thumbnail' size is bigger than 'imagefile' size in biblioimages table
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21987 Bug ID: 21987 Summary: Local cover 'thumbnail' size is bigger than 'imagefile' size in biblioimages table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: arouss1980(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We use local cover images in our setup, and also resize the covers we scan to a width of 160px before uploading and attaching them to a Koha bibliographic record (we upload one cover per biblio). While using phpMyAdmin to view the contents of the 'biblioimages' table (relevant screenshot here: https://imgur.com/a/cSEVLBI) we noticed that the size of the BLOBs for the 'thumbnail' column was in some cases twice as big as that of the 'imagefile' column. In fact, this happens for more than 50% of uploaded covers as you can see from the output of the SQL queries below: mysql> SELECT COUNT( * ) AS count FROM biblioimages WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ; +-------+ | count | +-------+ | 1356 | +-------+ mysql> SELECT COUNT( * ) AS count, SUM( LENGTH( imagefile ) ) AS images_size, SUM( LENGTH( thumbnail ) ) AS thumbnails_size FROM biblioimages ; +-------+-------------+-----------------+ | count | images_size | thumbnails_size | +-------+-------------+-----------------+ | 2347 | 68323933 | 115839686 | +-------+-------------+-----------------+ It would appear that for each 160px-wide JPG with 24-bit depth that we have uploaded, the 'imagefile' column has been populated with an PNG of 8-bit depth with the same dimensions as the uploaded file, whereas the 'thumbnail' column contains a 24-bit PNG image with a width reduced to 140 pixels. I've tracked down the creation of resized 24-bit PNGs to this code: https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183 Do thumbnails for covers need to be true colour (24-bit) images? Also, why is it that _scale_image() returns an image of 8-bit depth if the source image's dimensions are less than 600x800? (i.e. when no resizing is performed) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 23075] New: Incorrect URL should have a meaningful error message
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '19

06 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23075 Bug ID: 23075 Summary: Incorrect URL should have a meaningful error message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Target Milestone: --- Currently, if you input an incorrect mana service URL in your config (http rather than https for example) the error message you are given is the direct output of a failed json parse. We should be able to catch such failures and display a more meaningful error to the end user. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 68

[Bug 21406] New: Not adding author to request can cause JS errors
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '19

06 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21406 Bug ID: 21406 Summary: Not adding author to request can cause JS errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com If an ILL request does not contain an author, when viewing the ILL requests table, the following errors are displayed by Datatables: DataTables warning: table id=ill-requests - Requested unknown parameter 'metadata_Author' for row 0, column 0. For more information about this error, please see http://datatables.net/tn/4 DataTables warning: table id=ill-requests - Requested unknown parameter 'metadata_Author' for row 358, column 0. For more information about this error, please see http://datatables.net/tn/4 We need better handling of requests without populated author in the JS -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 20040] New: FailedLoginAttempts syspref will lock out users so that they cannot log in unless the syspref is cleared
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '19

06 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20040 Bug ID: 20040 Summary: FailedLoginAttempts syspref will lock out users so that they cannot log in unless the syspref is cleared Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org I think that the FailedLoginAttempts system preference is only meant to be set ifNorwegianPatronDBEnable is set to 'Enable'; my testing is all done with ifNorwegianPatronDBEnable set to 'Disable'. What's happening: Setting FailedLoginAttempts, then logging in with incorrect credentials will lock the account. The login screen says that the account is locked, and no further attempts to log in will work. It is entirely unclear how to unlock the account -- resetting the password does not work, and the lock is not set via borrower debarments, so it can't be disabled there. The only way I was able to re-enable logins for a locked patron was to blank out FailedLoginAttempts. If this is only meant to be used in conjunction with ifNorwegianPatronDBEnable, it shouldn't be settable unless that is enabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 22851] New: Style navigation links in serials modules like same links in other modules
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '19

06 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22851 Bug ID: 22851 Summary: Style navigation links in serials modules like same links in other modules 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 Target Milestone: --- Compare the links on the left between serials and acquisitions module. In aquisitions they are nicely styled, in serials they lack styling and are displayed as a simple button list. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 23082] New: Fatal error editing a restricted patron
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '19

05 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23082 Bug ID: 23082 Summary: Fatal error editing a restricted patron Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: frinaudo(a)infocpt.com.ar QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Para reproducir el error, se debe tener un socio con una restricción, ya sea manual o automática: 1- Editar el socio 2- Marcar el checkbox "eliminar" en la restricción 3- Guardar En ese momento aparece un internal server error En los logs el mensaje es: ==> /var/log/koha/eco/plack-error.log <== No property remove_debarment for Koha::Patron La restricción se elimina, pero se debe abrir una ventana de koha nuevamente. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 22128] New: koha-remove fails mysql ERROR 1133 (42000) at line 2: Can't find any matching row in the user table
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '19

04 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22128 Bug ID: 22128 Summary: koha-remove fails mysql ERROR 1133 (42000) at line 2: Can't find any matching row in the user table Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: Heinrich.Hartl(a)email.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Target Milestone: --- The script fails in in a GRANT command - the user does not exist This probably is due to changed behaviour of mysql 5.7ff From https://dev.mysql.com/doc/refman/5.7/en/grant.html#grant-overview: Note If an account named in a GRANT statement does not already exist, GRANT may create it under the conditions described later in the discussion of the NO_AUTO_CREATE_USER SQL mode. It is also possible to use GRANT to specify nonprivilege account characteristics such as whether it uses secure connections and limits on access to server resources. However, use of GRANT to create accounts or define nonprivilege characteristics is deprecated as of MySQL 5.7.6. Instead, perform these tasks using CREATE USER or ALTER USER. In my case mysql hosted a koha 16.11 database upgraded to 18.5 and the only existing user was koha_library@%. There was no user koha_library@localhost. mysql was running in the version (> 5.7)supplied with ubuntu 16.4 (Xenial). My solution to the problem was commenting out two lines in the script. diff /usr/sbin/koha-remove /usr/sbin/koha-remove_ori 71c71 < # GRANT USAGE ON \`koha_$name\`.* TO \`koha_$name\`@\`$mysql_hostname\`; --- > GRANT USAGE ON \`koha_$name\`.* TO \`koha_$name\`@\`$mysql_hostname\`; 73c73 < # DROP USER \`koha_$name\`@\`$mysql_hostname\`; --- > DROP USER \`koha_$name\`@\`$mysql_hostname\`; hhl@koha-VM-dev:~ > For a general solution the koha-remove script should be made more resilient and should not use deprecated mysql features. Since I am only very occasionally dealing with mysql and moreover I have no knowledge which user(s) have been used for koha instances in the past it is beyond my skills to define the proper revision of the script. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 20389] New: Indexing fields concatenated
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '19

04 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20389 Bug ID: 20389 Summary: Indexing fields concatenated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire.hernandez(a)biblibre.com I would like to be able to specify multiple subfields to index as a value in a field. The subfields must be concatenated. Example 1: Author in unimarc in an authority: 700 1 $a Bermès $b Emmanuelle I could record a fields in mappings: author: "700a. .700b" I would have in the field indexed: author: "Emmanuelle Bermès" Example 2: in mappings: author: "700b., .700a" would give: author "Bermès, Emmanuelle" With solr, we managed it with indexing plugins. If it is too early for this, we could manage it in mappings configuration maybe. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 22846] New: Remove warning in the manual about needing StaticHoldsQueueWeight to use RandomizeHoldsQueueWeight
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22846 Bug ID: 22846 Summary: Remove warning in the manual about needing StaticHoldsQueueWeight to use RandomizeHoldsQueueWeight Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The paragraph in https://koha-community.org/manual/18.11/en/html/systempreferences.html#stat… saying Leaving StaticHoldsQueueWeight empty is contraindicated at this time. Doing so will cause the build_holds_queue script to ignore RandomizeHoldsQueueWeight, causing the script to request hold fulfillment not randomly, but by alphabetical order. is talking about (without mentioning it by number) bug 8562, which was fixed in bug 12803 comment 14. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2