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

[Bug 34230] New: Add part_name and part_number to subscription result list
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '24

05 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34230 Bug ID: 34230 Summary: Add part_name and part_number to subscription result list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: michaela.sieber(a)kit.edu We added the subtitle to the subscription results, but as series often have similar names and are hard to distinguish, it would be great if part_name and part_number would also be shown to help to identify the correct entries (245$n and $p in MARC21). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 34199] New: Add part_name and part_number to subscription result list
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '24

05 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34199 Bug ID: 34199 Summary: Add part_name and part_number to subscription result list Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: michaela.sieber(a)kit.edu Depends on: 30205 Bug 30205 added the subtitle to the display, but as series often have similar names and are hard to distinguish, it would be great if part_name and part_number would also be shown (245$n and $p in MARC21). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30205 [Bug 30205] Add biblio.subtitle to the subscription-detail.pl page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

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

04 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