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

[Bug 13749] On loading holds in patron account 'processing' is not translatable
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13749 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org --- Comment #7 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- It does not appear on moremember, any ideas why? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13749] On loading holds in patron account 'processing' is not translatable
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13749 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #94964|0 |1 is obsolete| | --- Comment #6 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 95139 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95139&action=ed… Bug 13749: On loading holds in patron account 'processing' is not translatable This patch updates the DataTables configuration for two tables: The checkouts and holds lists shown on the checkout and patron details screen. The tables lacked the standard application of a custom set of defaults defined in js/datatables.js. It is in this file that custom language strings are defined for DataTable interface elements, pulling in the translated values from datatables.inc. Without our custom defaults applied, DataTables used its own defaults, which are not translated. To test, apply the patch and check out to a patron who has both checkouts and holds. The more the better to give you more time to observer the loading state of the tables. - Checkouts: This table doesn't exhibit any visible problems because page-specific text is defined for the table's "Loading" message. However, it still makes sense to apply the defaults to the table for consistency's sake. There should be no visible changes to the table. - Holds: From the checkout or patron details page click the "Holds" tab. While the table loads there should be a "Processing" message. If you switch to another translation the message should appear in that language. Signed-off-by: Katrin Fischer <katrin.fischer.83(a)web.de> Signed-off-by: Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13749] On loading holds in patron account 'processing' is not translatable
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13749 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15448] OPACHiddenItems show in OPAC when patron places a hold on a specific item
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15448 --- Comment #9 from Fridolin SOMERS <fridolin.somers(a)biblibre.com> --- (In reply to Katrin Fischer from comment #7) > (In reply to Fridolin SOMERS from comment #5) > > Maybe hidden items should be removed directly in C4::Items::GetItemsInfo, > > called by opac-reserve.pl > > Can you explain this a bit more? Not sure how it works right now, did you > mean move or remove? I mean remove, so they are never given to the OPAC. One should then add a new arg to the method to say opac or staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[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 11909] Fix hidelostitems, OpacHiddenItems total count, prog them facet display
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11909 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |RESOLVED Resolution|--- |WORKSFORME CC| |martin.renvoize@ptfs-europe | |.com --- Comment #18 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Sounds like this one is resolved.. marking as such. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13958] Add a suspensionsCalendar syspref
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13958 --- Comment #8 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Nice work! Pushed to master for 19.11.00 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13958] Add a suspensionsCalendar syspref
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13958 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |19.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13958] Add a suspensionsCalendar syspref
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13958 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Passed QA CC| |martin.renvoize@ptfs-europe | |.com --- Comment #7 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- This works as expected for me, and I'm pleased that the DB update takes the original settings into account. Trivial patch, passing QA. -- You are receiving this mail because: You are watching all bug changes.

1 0