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

[Bug 43343] New: Koha Date and Time Issue
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43343 Bug ID: 43343 Summary: Koha Date and Time Issue Initiative type: --- Sponsorship --- status: Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Sandboxes Assignee: koha-bugs(a)lists.koha-community.org Reporter: rashid.mahmood.satti(a)gmail.com CC: jonathan.druart(a)gmail.com, kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk Target Milestone: --- When I enter a new book record in Koha, the system displays or records the time approximately 8 hours behind the current local time. I have already checked the date and time settings on the Debian 12 server using the terminal. The server's date and time appear to be correct. However, when I enter a book in Koha, the time shown by Koha is approximately 8 hours earlier than the actual local time. I would like to know whether this is a Koha 26.05/26.5 bug or a timezone/configuration issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43341] New: Facets are appearing for items hidden via OpacHiddenItems
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43341 Bug ID: 43341 Summary: Facets are appearing for items hidden via OpacHiddenItems Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 14007 fixed the issue of values listed in OpacHiddenItems appearing in OPAC facets. However, there is still the issue of facet values appearing even when all items are hidden by another value being listed in OpacHiddenItems. To replicate on KTD (and to explain better): - Create a new LOC authorised value, e.g. R1 with the description Room 1. - Configure OpacHiddenItems with: "withdrawn: [1]" to hide all items with Withdrawn status 1 (labelled Withdrawn). - On a bib record, create two items. Set one of them to Shelving location = Room 1 and Withdrawn status = Withdrawn. Choose a different Shelving location and no Withdrawn status for the other. - Do the same on a second bib record. - Run a blank search on the OPAC. Notice that Room 1 appears in the Shelving location facet. - Filter by Room 1 facet and check the results. Notice that the Room 1 items are hidden, because they are withdrawn. So there are no Room 1 items visible in the OPAC and the value should not appear in the facet. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 21173] New: Run auto item modifications by age every hour and set the item age unit to hours
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21173 Bug ID: 21173 Summary: Run auto item modifications by age every hour and set the item age unit to hours 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Make auto item modification by age cronjob run more often than once daily. Setting this cronjob to run every hour will be set in the /etc/cron.hourly/koha-common. However 2 further changes to the automatic item modification tool to make an hourly running cronjob useful. 1. Be able to set the age of the item in hours not just days. This is so an hourly cronjob has items to alter because items will exceed the age limit more frequently than if the item age is in hours. 2. Give the user the choice of what the age starting point (time from which the age of the item is calculated) used in the cronjob is. The two possible age starting points that users have to choose between are: * Item creation (this is the age starting point in master currently) * Item last altered This is so items whic have been in the catalogue for a while can still be affected by the automatic item modification by age cronjob. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 77

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43341 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43341 [Bug 43341] Facets are appearing for items hidden via OpacHiddenItems -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 --- Comment #42 from David Cook <dcook(a)prosentient.com.au> --- Ah crumbs I meant to comment on this earlier... I'm guessing it'll be an ES specific issue and it'll have to do with facet names not matching the SQL fields... but I'll need to review bug 43341... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41880] New: Logs for moved holds don't indicate original bib number/item number
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41880 Bug ID: 41880 Summary: Logs for moved holds don't indicate original bib number/item number Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a hold is moved from bib A to bib B (or from item A to item B), and no change was made to the hold before the move, there is no way to identify the bib or item number of the original hold. To replicate: -Place a hold on bib A (or item A) -View it in Tools > Logs using the reserve_id. As is standard, no details other than the reserve_id show in the Info column. -Move the hold to bib B (or item B) -Run the holds log again for the reserve_id. Note that an entry is generated for the move, but only the bib number (or item number) it was *moved to* shows. There is no way to know what bib or item the hold was moved *from*. If a change is made to a hold before it's moved, staff will be able to see the original bib number/item number in logs. But there are likely to be many cases where the first change made to a hold is moving it to a new bib/item, which means that the original bib number/item number will be untraceable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 41883] New: Modifications using batch hold modification tool aren't logged
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41883 Bug ID: 41883 Summary: Modifications using batch hold modification tool aren't logged Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Changes made via the batch hold modification tool that are logged when made to holds individually from the bib are not logged when using the tool. To replicate: -Place a hold -Run the Holds log using the hold's reserve_id. There will be a single entry for the hold's creation. -Find the hold using the batch hold modification tool, and update its pickup location -Run the Holds log for that hold, and note that no entry has been generated for the changed pickup location -From the bib's Holds tab, update the same hold's pickup location -Run the Holds log again for that hold, and note that an entry was generated for the pickup location change when it was updated from the bib The same issue applies for updating expiration dates and for suspending/unsuspending, all of which do generate log entries when performed on individual holds from the bib. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 41801] New: FixPriority recursive calls for lowestPriority holds can be removed
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41801 Bug ID: 41801 Summary: FixPriority recursive calls for lowestPriority holds can be removed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Currently, C4::Reserves->FixPriority adjusts the holds not marked for lowestPriority, then recursively calls itself for each lowestPriority hold, touching all the non-found holds on the record each time. This can be removed as we can simply sort the lowestPriority holds to the bottom when getting the list of holds to adjust -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 42534] New: wrapper-staff-tool-plugin.inc interferes with js and includes in template files
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42534 Bug ID: 42534 Summary: wrapper-staff-tool-plugin.inc interferes with js and includes in template files Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Wrapper changes in Bug 42163 to support the vue changes made in Bug 41367 means you can't use a separate [% MACRO jsincludes BLOCK %] in plugins. Additionally if you're using any includes (such as datatables.inc) they no longer load because the wrapper [% MACRO jsincludes BLOCK %] overrides any inline [% MACRO jsincludes BLOCK %] You can use [% INCLUDE datatables.inc %] outside the wrapper, but most examples have it inside and I fear plugins using the wrapper will break on an update to 26.05. You can also put your <script> after the wrapper for loading it. We could try and make changes to the plugin structure/wrapper to make this work a little smoother. We could add common includes like datatable, calendar, select2, etc into the wrapper, but that seems like a long term maintenance issue. Another way could be to undo the vue change/figure out another way to load the admin menu or otherwise contain it so it's not overriding in page [% MACRO jsincludes BLOCK %] This would be the least disruptive for existing plugins, so is probably the way to go, but I'm not sure there's a good way to handle this. I'm very open to ideas about how to best handle this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42163] New: wrapper-staff-tool-plugin.inc no longer loads the admin menu
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42163 Bug ID: 42163 Summary: wrapper-staff-tool-plugin.inc no longer loads the admin menu Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 41367 broke the wrapper for the plugin and it no longer loads on plugins when using the wrapper. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65