Bug 39419 - Holds API treats 'expiration_date' as 'patron_expiration_date'
Summary: Holds API treats 'expiration_date' as 'patron_expiration_date'
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Brendan Lawlor
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-21 19:40 UTC by Nick Clemens (kidclamp)
Modified: 2025-08-20 15:26 UTC (History)
7 users (show)

See Also:
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 (11.53 KB, patch)
2025-08-19 19:37 UTC, Brendan Lawlor
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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