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

[Bug 11299] Add a button to automatically link authority records in cataloguing (AJAX)
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11299 Michal Denar <black23(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95126|0 |1 is obsolete| | --- Comment #104 from Michal Denar <black23(a)gmail.com> --- Created attachment 95152 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95152&action=ed… Bug 11299 - Add a button to the biblio edition page to automatically add authority links in the current biblio record via AJAX. Also adds a button to easily create missing authority records. add authority type in the form to create the missing authority. when authority was found, the 600$9 field have the authid. Testing scenario (Creating an authority record for a failed automatic link) : * In you system preferences, deactivate the "AutoCreateAuthorities" preference. * Go to the biblio record creation form to create a new biblio record. (koha/cataloguing/addbiblio.pl) * Click the "Link authorities automatically" button. A message should appear, telling the user "No authority link was changed." * Add random informations in field 600$a of the biblio record. * Click the "Link authorities automatically" button. * if matching authority was found, The message box should now show "600 - A matching authority was found in the local database". * if no matching authority was found, the message box should now show "600 - No matching authority found.". For this scenario, we want the authority match to have failed. * The 600$9 field should now be red and icons should have appeared next to it. Click on the "create authority" icon. * A popup will appear, containing a form to create the missing authority. The form should be pre-filled, a the informations in the 600$a field of the biblio should be in the 100$a field of this new authority record. * Fill in the form and click the "Save" button * The 600$9 field in the biblio record should now be back to normal and have the authid of the authority record that was just created. * Click the "Link authorities automatically" button again. The message box should now show "No authority link was changed.". Signed-off-by: Katrin Fischer <katrin.fischer.83(a)web.de> https://bugs.koha-community.org/show_bug.cgi?id=12299 Signed-off-by: Michal Denar <black23(a)gmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11299] Add a button to automatically link authority records in cataloguing (AJAX)
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11299 Michal Denar <black23(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Improve FindDuplicate
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Séverine Queune <severine.queune(a)bulac.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |severine.queune(a)bulac.fr -- 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 ---------------------------------------------------------------------------- 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