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

[Bug 23333] New: Course Reserves: Instuctor search box positioning
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23333 Bug ID: 23333 Summary: Course Reserves: Instuctor search box positioning Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire_gravely(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 91567 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91567&action=ed… Screenshot When creating a new course in the course reserves module the "Instructor search" box is oddly positioned. Perhaps it could be moved more in line with 'Instructors'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 23125] New: Tabs in patron account adjust to window size but text does not
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23125 Bug ID: 23125 Summary: Tabs in patron account adjust to window size but text does not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In the patron account in the OPAC the size of the tabs will shrink when resizing the window to a smaller width. This happens independent from the text inside, the text will break onto mulitple lines if it can, but that doesn't work for every language. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 39390] New: Booking pre-processing and post-processing days can be set for same day
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39390 Bug ID: 39390 Summary: Booking pre-processing and post-processing days can be set for same day Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Adjacent bookings are allowing the same day to be used as both a pre-processing and post-processing day. One should block the other. To recreate: 1. First, make sure that the item used in steps below is bookable and that it has at least a three week circulation period. 2. In circ rules, under "Default holds and bookings policies by item type," for an item type, set Booking pre-processing (days) to 1 and Booking post-processing (days) to 1. 3. Set up a booking for an item in that item type that starts on 13 May and ends 26 May. The pre-processing day is set for 12 May and the post-processing day is set for 27 May. 4. Submit the booking and see that the Start date is 13 May and the end date is 26 May. 5. Attempt to place a new booking for the same item. Notice that the first booking is grayed out on the calendar, but 12 May and 27 May, which should be pre- and post- processing days, show as eligible. Set dates as 28 May to 05 June, with pre-processing day of 27 May and post-processing day of 06 June. The booking will submit successfully. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 41405] New: Patron categories noissuescharge values default to 0 when not set
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41405 Bug ID: 41405 Summary: Patron categories noissuescharge values default to 0 when not set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To recreate: 1 - In a new KTD, check the values for a category: SELECT * FROM categories WHERE categorycode ='B'\G 2 - By default these three columns are null: noissuescharge: NULL noissueschargeguarantees: NULL noissueschargeguarantorswithguarantees: NULL 3 - If they are not, set them so: UPDATE categories SET noissuescharge=NULL, noissueschargeguarantees=NULL, noissueschargeguarantorswithguarantees=NULL; 4 - Open the category in staff interface: More->Administration->Patron categories->Edit 5 - Note the three inputs are set to 0 Checkout charge limit Guarantees checkout charge limit Guarantors with guarantees checkout charge limit 6 - Save the entry without making changes 7 - Check the DB as in Step 1 8 - Note all values are 0 9 - Edit and black the inputs and save 10 - Check the DB 11 - Note all value are now undef We should not have to edit the form to prevent changes -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 41511] New: Allow configuration of calendar widget for custom item fields in frameworks
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41511 Bug ID: 41511 Summary: Allow configuration of calendar widget for custom item fields in frameworks Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a library is adding custom fields to items the content is saved to more_subfields_xml, which is not a date or datetime field. The calendar widget won't show for these fields and cannot be activated by configuration. It would be nice if there was a flag in the framework configuration to say "treat this as a date field". This could also be helpful for other fields on record level. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14962] Temp Shelving Location
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 --- Comment #42 from Jake Deery <jake.deery(a)openfifth.co.uk> --- Hi David, Thanks for keeping tabs on this bug. I'm going to upload the tests in the next few working days, along with a plan. I'll reach out on Mattermost when thats done so you can have a look! Thanks, Jake -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38910] New: AutoLocation -> StaffLoginRestrictLibraryByIP
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '26

02 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38910 Bug ID: 38910 Summary: AutoLocation -> StaffLoginRestrictLibraryByIP Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de The "Implementation Checklist" https://koha-community.org/manual/latest/en/html/implementation_checklist.h… refers to `AutoLocation` which was renamed in Koha 24.05 to `StaffLoginRestrictLibraryByIP`. This should also be noted in the checklist "somehow". (May be difficult as the "old" name is still correct for some versions.) **Note** that upon following the link to the settings there is already a clear nore to the name change. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 33674] New: Landscape cover images are resized ignoring if image/book cover width > height
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33674 Bug ID: 33674 Summary: Landscape cover images are resized ignoring if image/book cover width > height Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: steve(a)softwaremage.co.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The code fragments below (/Koha/CoverImage.pm) need to determine if the width is greater than the height before resizing and creating the thumbnails and 'fullsize' image version. Otherwise wide books are always resized as if they were tall books. As a result the thumbnails and fullsize images of wide books are always scaled smaller than their 'portrait' counterparts. Needless to say these hardcoded values should be part of system preferences. They were set before the days of 4K monitors. I think that might be an open item. sub new { my ( $class, $params ) = @_; my $src_image = delete $params->{src_image}; if ( $src_image ) { ; # GD autodetects three basic image formats: PNG, JPEG, XPM; we will convert all to PNG which is lossless... # Check the pixel size of the image we are about to import... my $thumbnail = $class->_scale_image( $src_image, 140, 200 ) ; # MAX pixel dims are 140 X 200 for thumbnail... my $fullsize = $class->_scale_image( $src_image, 600, 800 ) ; # MAX pixel dims are 600 X 800 for full-size image... $params->{mimetype} = 'image/png'; $params->{imagefile} = $fullsize->png(); $params->{thumbnail} = $thumbnail->png(); } return $class->SUPER::new($params); } sub _scale_image { my ( $self, $image, $maxwidth, $maxheight ) = @_; my ( $width, $height ) = $image->getBounds(); if ( $width > $maxwidth || $height > $maxheight ) { my $percent_reduce; # Percent we will reduce the image dimensions by... if ( $width > $maxwidth ) { $percent_reduce = sprintf( "%.5f", ( $maxwidth / $width ) ) ; # If the width is oversize, scale based on width overage... } else { $percent_reduce = sprintf( "%.5f", ( $maxheight / $height ) ) ; # otherwise scale based on height overage. } my $width_reduce = sprintf( "%.0f", ( $width * $percent_reduce ) ); my $height_reduce = sprintf( "%.0f", ( $height * $percent_reduce ) ); my $newimage = GD::Image->new( $width_reduce, $height_reduce, 1 ) ; #'1' creates true color image... $newimage->copyResampled( $image, 0, 0, 0, 0, $width_reduce, $height_reduce, $width, $height ); return $newimage; } else { return $image; } } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 37701] New: Log viewer doesn't show everything when Module 'All' is checked
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37701 Bug ID: 37701 Summary: Log viewer doesn't show everything when Module 'All' is checked Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Find a record and do 1 edit to the record. 2. Also do 1 edit to an item on that record. 3. From the navbar on the left click 'Modification log' 4. You should see both the item and record modifications in log. 5. Notice also that the 'Catalog' module checkbox is checked by default 6. Now check 'All' instead and click 'Submit' 7. Now the item modification is gone, you only see the record modification. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 33633] New: Check if email exists
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33633 Bug ID: 33633 Summary: Check if email exists 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Is there any kind of mechanism available for Koha to use to test the existence of an email address before actually trying to send an email? It seems like there should be some way to ask email servers if the address at least exists, if not asking the status of the account, so it can make an informed decision on sending notices. Right now, Koha just sends to the address without knowing anything. If it doesn't exist, or is full, or blocked, then it is up to staff to figure it out and pass that information along to the patron. If there is some way to figure this out before sending, then we would be able have Koha do something else, like send to a secondary email address, text, phone, restrict the account, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18