Bug 41456

Summary: Item type filter on the hold history view does not work correctly
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: CirculationAssignee: Jonathan Druart <jonathan.druart>
Status: Pushed to stable --- QA Contact: Martin Renvoize (ashimema) <martin.renvoize>
Severity: normal    
Priority: P5 - low CC: david, gmcharlt, kyle, lucas
Version: unspecified   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
This fixes the patron's holds history table in the staff interface. The search filter now works as expected - using the library name or library code and requested item type name or item type code (when AllowHoldItemTypeSelection is enabled) now work as expected, and the column filters for both of these now use dropdown lists.
Version(s) released in:
26.05.00,25.11.01
Circulation function:
Bug Depends on: 41451    
Bug Blocks: 41457, 41530    
Attachments: Bug 41456: Fix item type searching and filtering on the holds history table
Bug 41456: Fix item type searching and filtering on the holds history table
Bug 41456: Fix item type searching and filtering on the holds history table
Bug 41456: Rename more item_type => item_type_id in hold's api spec
Bug 41456: Rename more item_type => item_type_id in hold's api spec
Bug 41456: (follow-up) Change item_type to item_type_id and add _strings in test data

Description Jonathan Druart 2025-12-16 12:29:44 UTC
We should be able to search using the item type's code or description. We also need to have the item types listed in a dropdown list.
Comment 1 Jonathan Druart 2025-12-16 12:43:01 UTC
Created attachment 190537 [details] [review]
Bug 41456: Fix item type searching and filtering on the holds history table

Use should use coded_values for the library and item type column so that
we can search using the code and the description.

With this patch we now have a dropdown list with the libraries and item
types in the table's headers.

Test plan:
0. Turn on AllowHoldItemTypeSelection
1. Create a hold and select an item type
Note: I think there is a bug if you select it from "Hold next available
item", use "Hold details". Please confirm?
2. Go to the holds history view
3. Filter and search by item type description and code. Same for
   library.
   Use the dropdown list in the headers.
Comment 2 David Nind 2025-12-16 16:27:54 UTC
Created attachment 190553 [details] [review]
Bug 41456: Fix item type searching and filtering on the holds history table

Use should use coded_values for the library and item type column so that
we can search using the code and the description.

With this patch we now have a dropdown list with the libraries and item
types in the table's headers.

Test plan:
0. Turn on AllowHoldItemTypeSelection
1. Create a hold and select an item type
Note: I think there is a bug if you select it from "Hold next available
item", use "Hold details". Please confirm?
2. Go to the holds history view
3. Filter and search by item type description and code. Same for
   library.
   Use the dropdown list in the headers.

Signed-off-by: David Nind <david@davidnind.com>
Comment 3 David Nind 2025-12-16 16:30:00 UTC
For step 1, if I select "Request specific item type" (Books):

- from under the "Hold next available item" section, it shows in the patron's holds history as "Any item type" (doesn't matter what I select here)

- from under "Hold details" section, it shows in the patron's holds history as "Book"
Comment 4 Martin Renvoize (ashimema) 2025-12-23 14:37:30 UTC
Created attachment 190702 [details] [review]
Bug 41456: Fix item type searching and filtering on the holds history table

Use should use coded_values for the library and item type column so that
we can search using the code and the description.

With this patch we now have a dropdown list with the libraries and item
types in the table's headers.

Test plan:
0. Turn on AllowHoldItemTypeSelection
1. Create a hold and select an item type
Note: I think there is a bug if you select it from "Hold next available
item", use "Hold details". Please confirm?
2. Go to the holds history view
3. Filter and search by item type description and code. Same for
   library.
   Use the dropdown list in the headers.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 5 Lucas Gass (lukeg) 2025-12-29 17:00:52 UTC
Nice work everyone!

Pushed to main for 26.05
Comment 6 Lucas Gass (lukeg) 2025-12-31 14:23:20 UTC
This seems to have broken Cypress tests:


cypress run --spec /kohadevbox/koha/t/cypress/integration/KohaTable/PendingHolds_spec.ts

Error: Properties not allowed: item_type_id.
    at /kohadevbox/koha/t/cypress/plugins/dist/api-client.cjs.js:303:55
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    1) "before each" hook for "Should render library filters"
    2) "after each" hook for "Should render library filters"


  0 passing (3s)
  2 failing



Can you have a look?
Comment 7 Lucas Gass (lukeg) 2025-12-31 16:55:08 UTC
Also causing t/db_dependent/api/v1/holds.t to fail, I believe.
Comment 8 Jonathan Druart 2026-01-05 15:35:13 UTC
This might be a problem...
I remembered I thought about that when I wrote the original patch but then forgot to add a warning about it: we are modifying the REST API spec, and what the route accepts/returns.

I would like Tomas and/or Martin's thinking on this one.

We may want to revert the first patch, but IMO the change is correct (item_type => item_type_id), and acceptable if we only push it to 26.05.00 and don't backport it.
Comment 9 Jonathan Druart 2026-01-05 15:36:17 UTC
Created attachment 190894 [details] [review]
Bug 41456: Rename more item_type => item_type_id in hold's api spec

Patch from commit b475de2
Comment 10 Martin Renvoize (ashimema) 2026-01-06 09:31:09 UTC
Created attachment 190919 [details] [review]
Bug 41456: Rename more item_type => item_type_id in hold's api spec

Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 11 Martin Renvoize (ashimema) 2026-01-06 09:32:22 UTC
As discussed on Mattermost, I believe the follow-up is the right approach here and I've tested it and confirmed it's good (PQA)

I think we should also look at the codebase for other instances of this being inconsistent and fix those in follow-up bugs
Comment 12 Lucas Gass (lukeg) 2026-01-06 14:34:17 UTC
Nice work everyone!

Pushed to main for 26.05
Comment 13 Lucas Gass (lukeg) 2026-01-14 14:19:16 UTC
I think this might now be causing t/cypress/integration/t/insertData.ts to fail. I'm not 100% certain but it's my best guess right now.
Comment 14 Lucas Gass (lukeg) 2026-01-14 14:34:09 UTC
Created attachment 191418 [details] [review]
Bug 41456: (follow-up) Change item_type to item_type_id and add _strings in test data
Comment 15 Lucas Gass (lukeg) 2026-01-14 15:51:13 UTC
follow-up pushed
Comment 16 Jacob O'Mara 2026-01-16 17:19:33 UTC
Thanks all, pushed to 25.11.x