Bug 41451

Summary: Hold history search fails when itemtype column present
Product: Koha Reporter: Matt Blenkinsop <matt.blenkinsop>
Component: CirculationAssignee: Jonathan Druart <jonathan.druart>
Status: Signed Off --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: david, gmcharlt, jonathan.druart, kyle
Version: Main   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
This fixes filtering on a patron's holds history when AllowHoldItemTypeSelection is enabled. This previously produced a 500 error when searching, but now works as expected.
Version(s) released in:
Circulation function:
Bug Depends on: 35560    
Bug Blocks: 41456    
Attachments: Bug 41451: Set correct embed and column property for itemtypes in the holds history table
Bug 41451: Set correct embed and column property for itemtypes in the holds history table
Bug 41451: Set correct embed and column property for itemtypes in the holds history table
Bug 41451: Prevent 500 when searching hold history
Bug 41451: Prevent 500 when searching hold history

Description Matt Blenkinsop 2025-12-15 17:04:01 UTC
The search box on the holds history table throws a 500 error when the item type column is visible

Test plan:
1) Create at least one hold on any record
2) Navigate to the patron who has the hold and click Holds history in the left menu
3) The table should load correctly and the search bar above it should work
4) In system preferences, enable AllowHoldItemTypeSelection
5) Refresh the holds history, the Requested item type column should now be visible
6) Try a search, a 500 error should be thrown
Comment 1 Matt Blenkinsop 2025-12-15 17:06:34 UTC
Created attachment 190519 [details] [review]
Bug 41451: Set correct embed and column property for itemtypes in the holds history table

Test plan:
1) Create at least one hold on any record
2) Navigate to the patron who has the hold and click Holds history in the left menu
3) The table should load correctly and the search bar above it should work
4) In system preferences, enable AllowHoldItemTypeSelection
5) Refresh the holds history, the Requested item type column should now be visible
6) Try a search, a 500 error should be thrown
7) Apply patch and run yarn api:bundle && restart_all
8) Repeat step 5, the search should now work correctly
Comment 2 David Nind 2025-12-15 17:43:25 UTC
I can reproduce the 500 error.

However, after applying the patch (+ yarn build, restart_all, delete browser history, and so on), the holds history page just sits with "Processing" for the current holds table.

In the developer tools browser console I'm getting: Uncaught TypeError: Cannot read properties of null (reading 'itemtype')
Comment 3 Matt Blenkinsop 2025-12-16 09:23:28 UTC
Created attachment 190532 [details] [review]
Bug 41451: Set correct embed and column property for itemtypes in the holds history table

Test plan:
1) Create at least one hold on any record
2) Navigate to the patron who has the hold and click Holds history in the left menu
3) The table should load correctly and the search bar above it should work
4) In system preferences, enable AllowHoldItemTypeSelection
5) Refresh the holds history, the Requested item type column should now be visible
6) Try a search, a 500 error should be thrown
7) Apply patch and run yarn api:bundle && restart_all
8) Repeat step 5, the search should now work correctly
Comment 4 David Nind 2025-12-16 09:38:42 UTC
Created attachment 190533 [details] [review]
Bug 41451: Set correct embed and column property for itemtypes in the holds history table

Test plan:
1) Create at least one hold on any record
2) Navigate to the patron who has the hold and click Holds history in the left menu
3) The table should load correctly and the search bar above it should work
4) In system preferences, enable AllowHoldItemTypeSelection
5) Refresh the holds history, the Requested item type column should now be visible
6) Try a search, a 500 error should be thrown
7) Apply patch and run yarn api:bundle && restart_all
8) Repeat step 5, the search should now work correctly

Signed-off-by: David Nind <david@davidnind.com>
Comment 5 Jonathan Druart 2025-12-16 10:34:49 UTC
This patch is not correct, it's not the item's item_type but the hold's item_type.
Comment 6 Jonathan Druart 2025-12-16 12:42:10 UTC
Created attachment 190536 [details] [review]
Bug 41451: Prevent 500 when searching hold history

It explodes if the "Item type" column is displayed (ie. if
AllowHoldItemTypeSelection is set).

Test plan:
1) Create at least one hold on any record
2) Navigate to the patron who has the hold and click Holds history in the left menu
3) The table should load correctly and the search bar above it should work
4) In system preferences, enable AllowHoldItemTypeSelection
5) Refresh the holds history, the Requested item type column should now be visible
6) Try a search, a 500 error should be thrown
7) Apply patch
8) Repeat step 5, the search should now work correctly

Note that a couple of other bugs will be fixed on follow-up bug reports.
Comment 7 Jonathan Druart 2025-12-16 12:42:51 UTC
I've found way too many things that didn't work so I've decided to fix the 500 on this bug report to ease backport, then follow-up on separate bug reports.
Comment 8 David Nind 2025-12-16 15:45:23 UTC
Created attachment 190552 [details] [review]
Bug 41451: Prevent 500 when searching hold history

It explodes if the "Item type" column is displayed (ie. if
AllowHoldItemTypeSelection is set).

Test plan:
1) Create at least one hold on any record
2) Navigate to the patron who has the hold and click Holds history in the left menu
3) The table should load correctly and the search bar above it should work
4) In system preferences, enable AllowHoldItemTypeSelection
5) Refresh the holds history, the Requested item type column should now be visible
6) Try a search, a 500 error should be thrown
7) Apply patch
8) Repeat step 5, the search should now work correctly

Note that a couple of other bugs will be fixed on follow-up bug reports.

Signed-off-by: David Nind <david@davidnind.com>