January 2024 - Koha-bugs - lists.koha-community.org

[Bug 35835] New: Fix shebang for cataloguing/ysearch.pl
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '24

05 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35835 Bug ID: 35835 Summary: Fix shebang for cataloguing/ysearch.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See 35290 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 34726] New: Clicking the title of a record in cart creates URL with duplicate query strings
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '24

05 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34726 Bug ID: 34726 Summary: Clicking the title of a record in cart creates URL with duplicate query strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you click a title in the OPAC cart, it will create a URL like the following: http://localhost:8080/cgi-bin/koha/opac-detail.pl?biblionumber=114?biblionu… This is because of competing functionality in the template and the Javascript. The output of the following "biblio_a_href" is fed into "openBiblio". koha-tmpl/opac-tmpl/bootstrap/en/includes/html_helpers.inc [% BLOCK biblio_a_href -%] [%- IF Koha.Preference('BiblioDefaultView') == 'marc' -%] [%- SET this_biblio_href = "/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=" -%] [%- ELSIF Koha.Preference('BiblioDefaultView') == 'isbd' -%] [%- SET this_biblio_href = "/cgi-bin/koha/opac-ISBDdetail.pl?biblionumber=" -%] [%- ELSE -%] [%- SET this_biblio_href = "/cgi-bin/koha/opac-detail.pl?biblionumber=" -%] [%- END -%] [%- this_biblio_href | url %][% biblionumber | url -%] [%- END %] koha-tmpl/opac-tmpl/bootstrap/js/basket.js function openBiblio(dest,biblionumber) { var openerURL = dest + "?biblionumber=" + biblionumber; opener.document.location = openerURL; opener.focus(); } -- You are receiving this mail because: You are watching all bug changes.

1 8

[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

[Bug 19942] New: Children's search interface
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '24

04 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19942 Bug ID: 19942 Summary: Children's search interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Would like to see an alternative OPAC search for patrons geared towards children. Something like this: http://www2.hampton.lib.nh.us:8080/kids?config=default#/categories It would be easy enough to customize searches, but it would be great to be able to customize a background, and add big buttons to the search topics. You will notice that the general search bar at the top limits to children's materials, and the layout of the results is EXTREMELY kid friendly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 34701] New: Add x-koha-embed biblio to checkouts API route
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '24

03 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34701 Bug ID: 34701 Summary: Add x-koha-embed biblio to checkouts API route 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: katrin.fischer(a)bsz-bw.de CC: tomascohen(a)gmail.com When using the REST API to display the patron's account information in another application, it would be excellent if we had an easy way to get the title information with the list of checkouts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23361] New: Status transfert is missing on item of a rotating collection
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '24

03 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23361 Bug ID: 23361 Summary: Status transfert is missing on item of a rotating collection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 91742 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91742&action=ed… dialog box transfert Hi, The transfert status is missing when a return is made on an item belonging to a rotating collection. Test plan: - Put an item on a rotating collection - check out item -Set branch to a different branch - check in item - alert message is displayed "Please transfert item to holding branch Y. This item is part of a rotating collection". There is not the usual question that appears when a return is made on a document to be transferred. - in detail page of biblio, status is available, item is not in transfert status like "in transit from homebranch to holding branch". Regards Marjorie -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 33472] New: Error 500 when many items attached to bib record
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '24

03 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33472 Bug ID: 33472 Summary: Error 500 when many items attached to bib record Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have a customer that has bibliographic records with several hundred items attached to each. When searching for these records, an error 500 is displayed instead. Lowering OpacMaxItemsToDisplay from 750 to 75 enables the records to display, although now when you click on the link to view all physical records an error 500 is still generated. -- You are receiving this mail because: You are watching all bug changes.

1 9