https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39419 --- Comment #53 from Brendan Lawlor <blawlor@clamsnet.org> --- Thanks for catching that Pedro. The issue was in Koha/REST/V1/Holds.pm in edit(). Before it used $body->{patron_expiration_date} // $hold->patron_expiration_date, so a null in the PATCH body fell back to the stored date. Now it uses exists $body->{patron_expiration_date} ? $body->{patron_expiration_date} : $hold->patron_expiration_date; so null in the PATCH body clears the date, which is consistent with how expiration_date, hold_date and item_id work. The tests in t/db_dependent/api/v1/holds.t in edit() are for both bib and item holds. They cover a PATCH that only sends expiration_date checking that patron_expiration_date does not change and a Patch that sends null for both dates, checking that the dates are cleared. A test in t/db_dependent/Reserves.t in ModReserve() was added to check calling ModReserve with patron_expiration_date => undef I also made a couple fixes to a couple commit messages that had the wrong format for (follow-up) and (QA-follow up) -- You are receiving this mail because: You are watching all bug changes.