February 2023 - Koha-bugs - lists.koha-community.org

[Bug 31321] New: Remove GetItemsInfo from catalogue/detail.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '23

14 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31321 Bug ID: 31321 Summary: Remove GetItemsInfo from catalogue/detail.pl Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 31306 Blocks: 27272 Bug 27272 is going to remove C4::Items::GetItemsInfo in favour of Koha::Items->search_ordered. Here we are going to deal with catalogue/detail.pl Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27272 [Bug 27272] Move C4::Items::GetItemsInfo to Koha namespace https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31306 [Bug 31306] Add Koha::Items->search_ordered method -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 23148] New: Replace Bridge icons with transparent PNG files
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '23

14 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23148 Bug ID: 23148 Summary: Replace Bridge icons with transparent PNG files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I propose to replace the Bridge icon set's GIFs with transparent PNG files. I propose also that the new images omit the English text labels which are not translatable and are unlikely to match any particular library's item type terminology. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 32947] New: Best Indian Main Door Designs with Photos
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '23

14 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32947 Bug ID: 32947 Summary: Best Indian Main Door Designs with Photos Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: champdecor12(a)gmail.com Entrance doors are the early impression makers. It is therefore extremely important to come up with the most refined designs on this regard. Moreover, the design should meet the overall architecture of the building. https://www.decorchamp.com/interior-decoration/best-indian-main-door-design… -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 30248] New: Select2 elements randomly have small width
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '23

14 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30248 Bug ID: 30248 Summary: Select2 elements randomly have small width Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I have seen random reports from some Koha users that the select2 elements will sometimes not show in the admin preferences. So far, this has been limited to Chrome, but not consistently. I have seen this on my own computer. Our test server will show the element correctly, but our production server will not. And when ByWater looks at the same element on the same server with the same version of browser, it looks fine. If I look at the same page in Firefox it looks fine. The element is there, but it has a defined width of 2.22222px. I am suspect of the changes made in bug 28611. I am suspecting that some computers load the page too fast, and the width is being set before there is any data in the element, and therefore extremely small. If I change the width in CSS to a fixed width, it shows and works properly. This is a difficult issue to replicate and figure out on my end. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 9717] Local use recorded for holds/transfers
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '23

14 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9717 --- Comment #20 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Because there is no way to know, when scanning an item, if it is being scanned solely for a local use or 'browse', it makes it difficult to separate a specific 'browse' count from other things it is doing. In other ILS systems, I've seen a completely separate task button for counting browses. The problem with an all in one scan is, how does it know when something is only to be scanned as a browse, how does it know it is completing something else, or how does it know it should do both? If we had a preference to provide an isolated scan for browses, we could allow libraries to continue what they do with regular scanning elsewhere. Localuse would function just as it always does. But having the 'browse' feature on, it could provide another function on the top scan bar, and scanning items there could increment a totally new 'browse' counter - a new field in the item record. And it would do everything else that Koha already does if needed - process a return, trigger holds or transfers, mark items found, record a local use, etc. But the needed and specific 'browse' would be counted only if using that tab on the top input bar. It would be a purposeful scan to indicate something specific about that item, and not just an arbitrary count that could have been for any number of things other than a browsed item. Thoughts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 32936] New: Tag review 'Check list' search does not display search output
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '23

14 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32936 Bug ID: 32936 Summary: Tag review 'Check list' search does not display search output Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you do a 'Check list' search on the tags review page (/cgi-bin/koha/tags/review.pl) you should get one of the following search outputs displayed: - <search term> is neither permitted nor prohibited! - <search term> is permitted! - <search term> is prohibited! However, none of these get displayed on master. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32953] New: Hide closed baskets
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '23

13 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32953 Bug ID: 32953 Summary: Hide closed baskets 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if Koha hid closed baskets. Why do we need to wade through many closed baskets to deal with the open ones? Here is my workaround in the meantime: https://wiki.koha-community.org/wiki/JQuery_Library#Condense_Acquisition_Ba… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 14180] Make "Always show checkouts immediately" a global setting
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '23

13 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14180 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber(a)kit.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28674] New: old_reserves.item_level_hold and reserves.item_level_hold comments have typo "hpld" not "hold"
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '23

13 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28674 Bug ID: 28674 Summary: old_reserves.item_level_hold and reserves.item_level_hold comments have typo "hpld" not "hold" Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: bolshawh(a)parliament.uk The reserves and old_reserves table schemas have typos in the comments for the item_level_hold field. The comments say "Is the hpld placed at item level" but it should be "Is the hold placed at item level". The typo is in the 21.05, 20.11, 20.05 and 19.11 versions. http://schema.koha-community.org/21_05/tables/reserves.html http://schema.koha-community.org/21_05/tables/old_reserves.html -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 3150] Move emails for sending cart and list contents into notices tool
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '23

13 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3150 --- Comment #148 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 146566 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146566&action=e… Bug 3150: (follow-up) Use get_marc_contributors -- You are receiving this mail because: You are watching all bug changes.

1 0