Bug 24466

Summary: AllowHoldsOnPatronsPossessions and the REST API
Product: Koha Reporter: Magnus Enger <magnus>
Component: REST APIAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: P5 - low CC: gmcharlt, jonathan.druart
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25662
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Magnus Enger 2020-01-21 13:15:59 UTC
A library in Sweden has reported the following problem: 

AllowHoldsOnPatronsPossessions = Do not allow. 

A patron borroes a book. A hold on the same book is then placed, for the same patron, through the REST API:

curl --location --request POST 'https://{baseurl}/api/v1/holds/' \
--header 'Content-Type: text/plain' \
--header 'Authorization: Basic {base64-encoded user pwd}' \
--data-raw '{
"patron_id": {patronid},
"pickup_library_id": "{library}",
"biblio_id": {biblioid}
}'

And voila, the patron has a hold on a record from which they already have an item on loan, contrary to the setting of the AllowHoldsOnPatronsPossessions syspref. 

(I have not tested this, but do trust that the report from the library is accurate.)
Comment 1 Jonathan Druart 2020-01-22 10:06:37 UTC
I guess we need to move that block from request.pl to CanBookBeReserved:

347         { # alreadypossession
348             # Check to see if patron is allowed to place holds on records where the
349             # patron already has an item from that record checked out
350             if ( !C4::Context->preference('AllowHoldsOnPatronsPossessions')
351                 && CheckIfIssuedToPatron( $patron->borrowernumber, $biblionumber ) )
352             {
353                 $template->param( alreadypossession => 1, );
354             }
355         }
Comment 2 Jonathan Druart 2020-01-22 10:11:59 UTC
Maybe also get_opacitemholds_policy can be bypassed
Comment 3 Magnus Enger 2020-06-25 09:08:10 UTC
Still a problem in 19.11.06.000.
Comment 4 Magnus Enger 2020-09-02 11:39:43 UTC
This should be fixed by the patches on bug 22806, I think.

*** This bug has been marked as a duplicate of bug 22806 ***