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
Aspen bug report: https://aspen-discovery.atlassian.net/browse/DIS-537
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
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