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

[Bug 36470] New: Generate CHECKOUT, CHECKIN and HOLD digest notices should be generated at once, not amended over time
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '24

05 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36470 Bug ID: 36470 Summary: Generate CHECKOUT, CHECKIN and HOLD digest notices should be generated at once, not amended over time Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CHECKIN, CHECKOUT and HOLD digest notices are not generated "all at once", but we generate a notice with the first action and then keep amending it until the notice is sent. This creates a number of problems: * We cannot make sure to include current/updated information in the notice, this might lead to hold pick-up notices be sent out for already picked up holds for example. * We limit what we can do with TT and need to rely on repetition markers ----. This is non-standard and we often had them deleted and notices broken in support. ... >From bug 15278: > (In reply to Martin Renvoize from comment #23) > > > As for the --- digest thing, I feel like the logic for that one is backwards > > and strange.. we should be generating the notice all in one hit at a later > > point in time rather than queuing a notice and then munging extra stuff into > > it after the fact at various times. > > The --- digest thing also doesn't make much sense to me. > With putting it together at one point in time, would that mean that say for > hold notices when notices send every hour that before that happened it would > build and check for the patron any waiting holds that had been set to > waiting since the last one? > > Or perhaps we could set some sort of flag when the hold is trapped that gets > cleared when the notice is sent? If we know the exact time something was checked in, checked out or set to waiting, we might be able to use this information to build the notice. But then maybe need to remember when the last notice was sent? The flag might be a more reliable idea and also would make it easy to resend some or all whenever needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

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 36184] New: Receiving individual items in Preservation Module is unclear
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '24

04 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36184 Bug ID: 36184 Summary: Receiving individual items in Preservation Module is unclear Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Preservation Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com After creating a train with items, closing, and sending, receiving the items back is confusing. The table allows you to select an individual item but it is not clear what, if anything, happens. An item can be selected but the only option is to close the train once selected. It appears that a "train" can be received, but not individual items within the train. It would be nice to be able to receive individual items within a train. Much of this depends on the processing and workflow created. I can see groups of items being sent and individual items being received back one at a time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[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 04 Sep '24

04 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

[Bug 32132] New: Missing budget_period_id in aqbudgets kills lateorders.pl
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '24

03 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32132 Bug ID: 32132 Summary: Missing budget_period_id in aqbudgets kills lateorders.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org If column budget_period_id in aqbudgets table is NULL lateorders.pl, Koha dies on error 500. Logs read: Template process failed: undef error - DBIC result _type isn't of the _type Aqbudget at /home/koha/Koha/koha-tmpl/intranet-tmpl/prog/en/modules/acqui/lateorders.tt line 157. Of course solution for this is to fix missing values, but I think we should still prevent Koha dying on this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 33174] New: Have better indication when one is cancelling multiple holds on a record
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '24

03 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33174 Bug ID: 33174 Summary: Have better indication when one is cancelling multiple holds on a record Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Have a record with many holds 2. From request.pl select all the holds and press Cancel seleected(x) 3. A modal popup now appears that says "Are you sure you want to cancel this hold?" 4. It would be nice if this modal more clearly indicated that you are about to cancel many holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21