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

[Bug 22440] New: ILL API response objects inconsistent with other endpoints
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 Bug ID: 22440 Summary: ILL API response objects inconsistent with other endpoints Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Target Milestone: --- The response object returned from the /api/vi/illrequest GET route isn't consistent with response objects supplied by other routes, such as the patrons route. We have an RFC for this route here: https://wiki.koha-community.org/wiki/Illrequests_endpoint_RFC Josef has made some initial recommendations on what the properties should be named to make them consistent with other routes. We could do with expanding this RFC to make it complete, including a spec on how object embedding should be done since, to date, this is the only route that does this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 66

[Bug 23557] New: REST API: Add ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23557 Bug ID: 23557 Summary: REST API: Add ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Method POST /ill_requests https://wiki.koha-community.org/wiki/Illrequests_endpoint_RFC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[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 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 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