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

[Bug 19770] New: Add cardnumber to holds awaiting pickup screen and add classes to borrower info
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '19

12 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19770 Bug ID: 19770 Summary: Add cardnumber to holds awaiting pickup screen and add classes to borrower info Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some libraries use a combination of borrowers surname and cardnumber on hold slips, this seems to be a fairly common occurence. To facilitate this it would be nice to have the cardnumber available on the waiting holds report. Additionally it would be nice to have classes add to the borrower information so that they can be accessed via javascript for constructing the special code used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 20407] New: Hide some fields from unauthoriezd users
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '19

08 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20407 Bug ID: 20407 Summary: Hide some fields from unauthoriezd users Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com The main goal here is to be able to make some fields/properties/columns "non public" to unauthorized people ( permission => catalogue ) by setting a "x-public" key to false in Swagger definitions files. Patch is coming... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 22521] New: Convert fines handling to use 'status' instead of two accounttypes
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '19

08 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22521 Bug ID: 22521 Summary: Convert fines handling to use 'status' instead of two accounttypes 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 22512 introduces a new field for tracking the 'state' of various accounttypes; We should convert the current fine handling from using `FU` (denoting "fine unreturned/updating") in combination with `F` (denoting fine "fixed"). This will clarify the logic and also pave the way to having a more user definable accounttype configuration. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 161

[Bug 22997] New: Searching gives no results in auth_finder.pl
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '19

08 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22997 Bug ID: 22997 Summary: Searching gives no results in auth_finder.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Target Milestone: --- During cataloguing of an existing biblio, on an heading field, the use of tag editor fills authorities finder with existing value : Search main heading ($a only) Search main heading Default operator beeing 'contains'. Actually with Elasticsearch those search give no results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 15732] New: Remove accountno column from accountlines
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15732 Bug ID: 15732 Summary: Remove accountno column from accountlines Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 How that we have accountlines_id, accountno is superfluous. We should remove it. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 21683] New: Remove accountlines.accountno
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21683 Bug ID: 21683 Summary: Remove accountlines.accountno Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This database column is obsolete. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 94

[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 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