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

[Bug 26715] New: Make Z39.50 modal moveable in the Advanced Cataloging Editor
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26715 Bug ID: 26715 Summary: Make Z39.50 modal moveable in the Advanced Cataloging Editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful to be able to move the Z39.50 modal around the screen when performing a Z39.50 search while editing a record in the Advanced Cataloging Editor (editor.p) Sometimes after doing the Z39.50 search you need to see something in the original bib record and it ends up being obscured behind the modal causing you to have to close the modal in order to view the specific part of the bib record you needed to consult. Then you have to re-execute the Z39.50 search. It would be a great timesaver if you could move the modal around the screen to view all parts of the bib record behind it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 27677] New: Configure facets differently for OPAC and Staff Client
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27677 Bug ID: 27677 Summary: Configure facets differently for OPAC and Staff Client 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: severine.queune(a)bulac.fr Search logics and needs are different if you are a user or a librarian. It could be great if we could define two different orders for the facets for the OPAC and the staff client, and if we could hide/show a facet in an interface but not the other one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29606] New: Include items from host record in XML for XSLT processing
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29606 Bug ID: 29606 Summary: Include items from host record in XML for XSLT processing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Searching Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If EasyAnalyticalRecords is enabled, items from host records should be included in the XML. Otherwise, OPAC search results show no items. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 29689] New: Update to 21.11 broken auto-generated barcode in <branchcode>0001 option
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29689 Bug ID: 29689 Summary: Update to 21.11 broken auto-generated barcode in <branchcode>0001 option Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jmhenrique(a)yahoo.com.br QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 128480 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128480&action=e… Error in Chrome console Hi! In version 21.05 the automatic barcode generator for manual addition of items worked. When upgrading to 21.11, it stopped working. The chrome debug shows the following message attached To reproduce the error, clicking on the item "p - barcode" generates the error on the console, and does not show any expected results. The autoBarcode option is set to "<branchcode>yymm0001" . Other autoBarcode options work except "<branchcode>aamm0001" . -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 28103] New: Barcode fails when adding item during order receival
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28103 Bug ID: 28103 Summary: Barcode fails when adding item during order receival Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: Needs Signoff Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Severity: normal Status: Needs Signoff Set "AcqCreateItem" to "receiving an order" Set "autoBarcode" to "generated in the form <branchcode>yymm0001" Create an order and go to receive it at a path like /cgi-bin/koha/acqui/orderreceive.pl?ordernumber=2&invoiceid=1 When you try to generate a barcode, you should get a Javascript error like this in the console: Uncaught TypeError: Cannot read property 'field_value' of null It's because the form can't be selected by the Javascript written in C4/Barcodes/ValueBuilder.pm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 26717] New: Allow specifying where to insert new subfields in MARC Modification Templates
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '24

05 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26717 Bug ID: 26717 Summary: Allow specifying where to insert new subfields in MARC Modification Templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Bug 24480 comment 9 points out that the current system of adding subfields at the end of the field isn't always what someone will want. However, since many fields have a particular non-alphabetic order for subfields (in a personal name, subfield q (the fuller form of name) follows a, before dates in d) or a semantic meaning to the order of subfields (subject fields) or a variable order based on how you use them (if I used 521 I might be tempted to use $bFoo:$aBar to get a display of "Target Audience Setting Authority: Goats" rather than an unclear "Goats Target Audience Setting Authority"), fixing this will require figuring out what methods of specifying location can and should be supported, writing UI to specify them, and either adding those methods to MARC::Field (which only does "at the end") or just making "Add a subfield" actually be "Create a new field by copying the existing subfields of an existing field with one added and then delete the existing field" in the backend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28451] New: Message queue field "from_address" does not always get populated
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '24

04 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28451 Bug ID: 28451 Summary: Message queue field "from_address" does not always get populated 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The message_queue table column "from_address" does not always get populated. We should either make the EnqueueLetter parameter 'from_address' mandatory, or (preferably) derive the correct from address from the letter's branchcode. If the letter has no branchcode, I imagine we should use either the KohaAdminEmailAddress or the patron's home library's email address. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26477] New: Emaillibrarianwhenholdisplace may be change to specify email as per library choice
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '24

04 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26477 Bug ID: 26477 Summary: Emaillibrarianwhenholdisplace may be change to specify email as per library choice Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: mishravk79(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hello Emaillibrarianwhenholdisplace may be more helpful if we make it customisable as per choice of the library. It will help library to specify the email of librarian who is dealing with Hold related services in the library. Thanking You -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 23984] New: Local cover 'thumbnail' size is bigger than 'imagefile' size in biblioimages table
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '24

04 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23984 Bug ID: 23984 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: arouss1980(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, lucas(a)bywatersolutions.com, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 21987 Blocks: 23963 The original resolution to this issue, bug 21987, caused a nasty regression and has since been reverted. Opening this bug so we may pursue a new route to goal. +++ This bug was initially created as a clone of Bug #21987 +++ 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) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21987 [Bug 21987] Local cover 'thumbnail' size is bigger than 'imagefile' size in biblioimages table https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23963 [Bug 23963] Visible reduction in image quality -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 31049] New: Add tool to set/reduce local cover image size and quality, interactively and in batch.
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '24

04 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31049 Bug ID: 31049 Summary: Add tool to set/reduce local cover image size and quality, interactively and in batch. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: egpetridis(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org It would be useful I think to add functionality that would a) process local cover images and set colour depth, resolution, quality and compression to certain levels set in authorized values at library level, before commiting new images to the database. b) process in batch images already existing in the db, according to the values set. c) store in the db settings used for each local cover image, so that it wouln't be re-processed unless new, lesser image quality settings were set and patch processing was invoked. It seems (Bug 21987 and Bug 22988) that some kind of processign is already performed but I found no related settings or documentation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9