Bug 39419

Summary: Holds API treats 'expiration_date' as 'patron_expiration_date'
Product: Koha Reporter: Nick Clemens (kidclamp) <nick>
Component: Hold requestsAssignee: Brendan Lawlor <blawlor>
Status: Needs Signoff --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: blawlor, chlee, esther.melander, gmcharlt, mspinney, piia.semenoff, rcoert
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: Small patch Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: Bug 39419: Enable Holds API to set expiration_date and patron_expiration_date independently

Description Nick Clemens (kidclamp) 2025-03-21 19:40:13 UTC
This is going to have a related issue in Aspen, but I think the confusion starts here

Koha has two fields for hold expiration:
expirationdate - (usually) auto generated date set based no when holds on the shelf expire
patron_exiration_date  - the day the patron says they don't need the hold after

The API takes "expiration_date" and maps it to "patron_expiration_date"

This can be unclear for outside systems.

Aspen has a 'Default Not Needed After Days' setting which is assumed to be setting the automatic expiraton date, but in fact sets the patron date

We should allow either field to be set via the API
Comment 1 Nick Clemens (kidclamp) 2025-03-21 19:43:32 UTC
Aspen bug report: https://aspen-discovery.atlassian.net/browse/DIS-537
Comment 2 Brendan Lawlor 2025-08-19 19:37:24 UTC
Created attachment 185568 [details] [review]
Bug 39419: Enable Holds API to set expiration_date and patron_expiration_date independently

This patch adds patron_expiration_date as a new parameter to the Holds API
for the add and edit methods.

To test:
1. Apply patch and restart_all
2. Make some requests to add holds like POST /api/v1/holds
   example body:
   {
     "biblio_id": "22",
     "patron_id": "42",
     "pickup_library_id": "FFL",
     "expiration_date": "2099-12-31",
     "patron_expiration_date": "3099-01-01"
  }
3. Verify that you can set the expiration_date and patron_expiration_date indepdently
4. Confirm that patron_expiration_date is a new field in the API response
5. Make note of the hold_id in the response for the next step
6. Make some requests to edit the hold like PATCH /api/v1/holds/{hold_id}
   example  body:
   {
     "patron_expiration_date": "2999-09-19",
     "expiration_date": "2031-09-19"
   }
7. Verify that you can set the expiration_date and patron_expiration_date indepdently
8. Make sure making and modifying holds isn't broken in the staff intterface or opac
Comment 3 Brendan Lawlor 2025-08-20 15:26:39 UTC
Maybe the changes to Reserves.pm and Hold.pm need tests?

There is a bit of extra logic that goes on with expirationdate and patron_expiration_date that is explained on bug 29975. I'm not clear on exactly how the API should work with relation to that though