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

[Bug 40838] New: Bookings related built CSS not ignored by Git
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40838 Bug ID: 40838 Summary: Bookings related built CSS not ignored by Git Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I think it was bug 40656 that introduced bookings.scss, and now we have: ```shell $ git status En la rama main Tu rama está actualizada con 'origin/main'. Archivos sin seguimiento: (usa "git add <archivo>..." para incluirlo a lo que será confirmado) koha-tmpl/intranet-tmpl/prog/css/bookings-rtl.css koha-tmpl/intranet-tmpl/prog/css/bookings.css ``` It's in spanish, but you get the point. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 35946] New: If an item has future bookings on it and it is marked as lost we should highlight this to the librarian
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35946 Bug ID: 35946 Summary: If an item has future bookings on it and it is marked as lost we should highlight this to the librarian 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 29002 If an item is made unavailable for bookings for some reason, we need to highlight to the end user that there are bookings outstanding against the item and that they'll need to resolve this somehow.. probably by assigning an alternate item to the booking or cancelling the booking and notifying the patron. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 37601] New: Add status field to bookings table
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37601 Bug ID: 37601 Summary: Add status field to bookings table Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The goal is to add a status column to the bookings table to track a bookings state Two existing ideas are: - confirmed (the default state for a freshly created booking, open for suggestions on a better name for this one) - cancelled For a follow-up bug: - active (booking is currently in the boundary of start and end date) - expired (bookings end date is in the past) - pending (bookings start date is in the future) should be calculated at runtime and zipped into the api response so that the datatable ordering and searching still works as expected. Additional opinions would be appreciated! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 37592] New: Add created_at, updated_at fields to bookings table
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37592 Bug ID: 37592 Summary: Add created_at, updated_at fields to bookings table Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 57

[Bug 39939] New: Cancel selected holds button on waitingreserves.pl is the same color as the background
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39939 Bug ID: 39939 Summary: Cancel selected holds button on waitingreserves.pl is the same color as the background Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It's hard to tell "Cancel Selected" on the Holds Awaiting Pickup screen is a button at all. It should have a different color than the background. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 33363] New: More specific permissions for purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33363 Bug ID: 33363 Summary: More specific permissions for purchase suggestions 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: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are a number of libraries that would like for their staff to be able to submit (and view existing) purchase suggestions from the borrower record, but not give the staff the ability to edit/manage/delete purchase suggestions. Currently if staff are given Suggestions Management/Manage Purchase Suggestions, and no Acq permissions, they are able to not only submit/view from the borrower record, but also access the purchase suggestion module and update/approve/delete purchase suggestions. If Suggestions Management is not turned on, then staff cannot enter a purchase suggestion from a borrower record, nor can they see them from the patron record to let the patron know what the status is. It would be helpful to have an addition permission level that would allow staff to enter a purchase suggestion from the borrower record, and view the existing purchase suggestions on a patron account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 41034] New: Automaticitemreturn and transfer limits interaction is very weird
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41034 Bug ID: 41034 Summary: Automaticitemreturn and transfer limits interaction is very weird Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com in C4/Circulation.pm around 2530 my $BranchTransferLimitsType = C4::Context->preference("BranchTransferLimitsType") eq 'itemtype' ? 'effective_itemtype' : 'ccode'; 2531 if (C4::Context->preference("AutomaticItemReturn" ) or 2532 (C4::Context->preference("UseBranchTransferLimits") and 2533 ! IsBranchTransferAllowed($branch, $returnbranch, $item->$BranchTransferLimitsType ) 2534 )) { 2535 my $transfer = ModItemTransfer($item->itemnumber, $branch, $returnbranch, $transfer_trigger, { skip_record_index => 1 }); 2536 $messages->{'TransferTo'} = $returnbranch; 2537 $messages->{'WasTransfered'} = $transfer->id; 2538 $messages->{'TransferTrigger'} = $transfer_trigger; # In this case we create a transfer and prompt the librarian "Reason for transfer:" 2539 } else { 2540 $messages->{'NeedsTransfer'} = $returnbranch; 2541 $messages->{'TransferTrigger'} = $transfer_trigger; # In this case we ask the librarian whether they want to transfer or not 2542 } These lines make no sense to me, in particular for following reasons: - If there is AutomaticReturn, a transfer will be created without informing the user, however it is forbidden - If there is no AutomaticReturn, and branchtransfers is forbidden from target branch to branch where we check-in (yes, in this direction), there will be a transfer without asking to the user. - Otherwise there is a confirmation box, even if it is a forbidden transfer, and there is no mention that the transfer is forbidden. If I understand well, there should be 3 cases. 1 - The transfer is not authorized, whatever the syspref AutomaticItemReturn, we inform the librarian that this situation should not have happened and tell to send the book to the proper library (should we there allow to create the transfer by forcing restrictions ?). 2 - The transfer is authorized, and there is an automatic transfer -> fall back in case 1 3 - The transfer is authorized, and there is no automatic transfer -> fall back in case 2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41041] New: Item type configured to hide item from OPAC, but shows in facets!
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41041 Bug ID: 41041 Summary: Item type configured to hide item from OPAC, but shows in facets! Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cgresser(a)jesuit.org.uk QA Contact: testopia(a)bugs.koha-community.org Created attachment 188044 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=188044&action=e… Screenshot shows facet of hidden from OPAC item type We have defined an item type which should be hidden on OPAC, yet as there are other items under the same biblio record they showed up, and then the facet for this item type showed on OPAC too. To add an option to configuration of item type to hide the facet for an item type from OPAC. Open Fifth created a workaround in OpacUserJS system preference to hide this facet from display: /* Hide Hidden itype from facets */ $("#itype_id > ul > li:has(span:contains('Item type hidden from OPAC'))").remove(); but it would be better if Koha did this as "out-of-the-box". I attach a screenshot of proof how it looked before Open Fifth applied the workaround to the display. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37737] Users with 'execute_reports' permission can create reports 23.11 and lower
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37737 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38414 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41014] New: Result browser not showing up in staff interface
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41014 Bug ID: 41014 Summary: Result browser not showing up in staff interface Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org The result browser is rendered from a javascript and inserted before the element with id="menu". But in bug 37222 the id changed to "biblio-view-menu", so the corresponding change needs to be made to the browser javascript. diff --git a/koha-tmpl/intranet-tmpl/prog/js/browser.js b/koha-tmpl/intranet-tmpl/prog/js/browser.js index 5a28fc8f198..a9cbf8ada97 100644 --- a/koha-tmpl/intranet-tmpl/prog/js/browser.js +++ b/koha-tmpl/intranet-tmpl/prog/js/browser.js @@ -165,7 +165,7 @@ KOHA.browser = function (searchid, biblionumber) { __("Next") + '"><i class="fa fa-arrow-right"></i></a>'; } - $("#menu").before( + $("#biblio-view-menu").before( '<div class="browse-controls"><div class="browse-controls-inner"><div class="browse-label"><a href="' + searchURL + '" id="browse-return-to-results" class="searchwithcontext"><i class="fa fa-list"></i> ' + -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1