Bug 21729 added to holds table the column patron_expiration_date. This must impact the REST API. Currently test suite is failing : https://jenkins.koha-community.org/view/master/job/Koha_Master_D10/516/testReport/
Created attachment 129961 [details] [review] Bug 29975: [DRAFT] fix API
(In reply to Fridolin Somers from comment #1) > Created attachment 129961 [details] [review] [review] > Bug 29975: [DRAFT] fix API This draft patch makes api test suite happy. But I don't know if it is the correct solution.
Created attachment 129988 [details] [review] Bug 29975: (bug 21729 follow-up) Fix api/v1/holds.t Unknown column 'patron_expiration_date' in 'field list' The REST API routes don't need to be aware of the new column patron_expiration_date
Thanks a lot for the real patch Jonathan :D
Created attachment 130058 [details] [review] Bug 29975: (bug 21729 follow-up) Fix api/v1/holds.t Unknown column 'patron_expiration_date' in 'field list' The REST API routes don't need to be aware of the new column patron_expiration_date Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Created attachment 130090 [details] [review] Bug 29975: Add missing patron_expiration_date attribute to hold spec On bug 21729 a new attribute was added to the holds objects, but we forgot to add it to the spec. This broke the holds routes. To test: 1. Run: $ kshell k$ prove t/db_dependent/api/v1/holds.t => FAIL: Tests fail, boo. 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests pass! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I revert what I did because Jonathan is right, this attribute is not strictly required on the API (yet?) so we should delay exposing it until there's a real need for it.
Created attachment 130092 [details] [review] Bug 29975: (bug 21729 follow-up) Fix api/v1/holds.t Unknown column 'patron_expiration_date' in 'field list' The REST API routes don't need to be aware of the new column patron_expiration_date Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
Just for clarification here: When creating a hold if an expirationdate is passed then it will be set as the patron_expiration_date When the patron_expiration_date is set, this is copied to the expiration_date When Koha sets an expiration date (when hold filled) it will use the lesser of the patron_expiration_date or the calculated date i.e. the expiration_date field in the api will represent the patron_expiration_date or the Koha expiration_date as appropriate i.e. The field is not so much hidden, as not needed externally - I didn't fully understand and leave this for others as muddled as me