June 2021 - Koha-bugs - lists.koha-community.org

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

05 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 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 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 19518] New: Document per-site .psgi files
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '24

03 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19518 Bug ID: 19518 Summary: Document per-site .psgi files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org koha-plack uses /etc/koha/plack.psgi by default, but it can also use /etc/koha/sites/${instancename}/plack.psgi if one is present. This should be documented in the manpage of koha-plack and the usage embedded in the script. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 21359] New: Add RDF support to OAI-PMH harvester
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '24

02 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21359 Bug ID: 21359 Summary: Add RDF support to OAI-PMH harvester Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The OAI-PMH harvester is set up to import only MARC records into Koha. The goal of this enhancement would be to allow RDF records to be imported into Koha as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 28009] New: Provide better feedback on import
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '24

29 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28009 Bug ID: 28009 Summary: Provide better feedback on import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There's a FIXME about extended attributes exception handling. With the work from bug 27857 and friends, we should be able to remove that FIXME and provide better feedback to the end user. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21893] New: Batch Modify button in report with itemnumber only includes titles in first page of results
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '24

29 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21893 Bug ID: 21893 Summary: Batch Modify button in report with itemnumber only includes titles in first page of results Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 19233 added the ability to push report results into item batch modification when the report includes a column of itemnumbers. However, only items on the first page of item results will be pushed to batch modification -- if the report results include 1200 items and the report page is set to display 1000 rows per page, only the first 1000 items will be batch modified. Koha is clear that it's only modifying those 1000 items, but it still creates extra work, especially since the Rows Per Page dropdown on report results doesn't include an option for All. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 25393] New: Create separate No Automatic Renewal Before rule
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '24

29 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25393 Bug ID: 25393 Summary: Create separate No Automatic Renewal Before rule 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha currently applies the No Renewal Before value to both manual and automatic renewal. Libraries that use a mix of manual and automatic renewal often don't want the same behavior between them - they want manual renewal to be possible earlier in the checkout even if automatic renewal doesn't happen until closer to the due date. We could address this by maintaining separate No Renewal Before values. For what it's worth, we already acknowledge this possibility when leaving No Renewal Before blank. For a manual renewal, no value in No Renewal Before allows renewal immediately. For an automatic renewal, no value in No Renewal Before does not allow renewal until the due date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67