No way to cancel a request? about vufind HOT 11 CLOSED

JIRA User: Jessica Gibson (gibsonjc)
JIRA Timestamp: 2016-04-05 12:46 PM

In config.ini:

; Determines if storage retrieval requests can be cancelled or not.
; Options are true or false.
; default is false
cancel_storage_retrieval_requests_enabled = false

from vufind.

JIRA User: Chris Delis (cedelis)
JIRA Timestamp: 2016-04-05 01:46 PM

Yay! Now the button / action shows up. But the actual cancel operation itself does not work. Working on it...

from vufind.

JIRA User: Jessica Gibson (gibsonjc)
JIRA Timestamp: 2016-04-06 07:14 AM

Debbie just stated this information yesterday in an unrelated RT ticket, so I thought I would note it here for reference:

The only time a request can be cancelled is when it has the status of "request submitted". This status happens at two occasions,

1. when you first place your request, before the lending library prints the pull-slip, and 2) when the request is not filled by one library and it is promoted overnight to the next library, before that new library prints the pull-slip.

from vufind.

JIRA User: Chris Delis (cedelis)
JIRA Timestamp: 2016-04-06 11:22 AM

I noticed that the AgencyId was missing in VuFind2's driver (XCNCIP.php):

ns1:RequestId
ns1:AgencyIdSICdb/ns1:AgencyId
ns1:RequestIdentifierValue487897/ns1:RequestIdentifierValue
/ns1:RequestId

This is needed in order to handle consortial environments.

Below, for reference, is the whole puzzle:

<ns1:NCIPMessage xmlns:ns1="http://www.niso.org/2008/ncip" ns1:version="http://www.niso.org/schemas/ncip/v2_0/imp1/xsd/ncip_v2_0.xsd">
ns1:CancelRequestItem
ns1:InitiationHeader
ns1:ToAgencyId
ns1:AgencyIdMILdb/ns1:AgencyId
/ns1:ToAgencyId
/ns1:InitiationHeader
ns1:AuthenticationInput
ns1:AuthenticationInputData/ns1:AuthenticationInputData
ns1:AuthenticationDataFormatTypetext/ns1:AuthenticationDataFormatType
ns1:AuthenticationInputTypeUsername/ns1:AuthenticationInputType
/ns1:AuthenticationInput
ns1:AuthenticationInput
ns1:AuthenticationInputData/ns1:AuthenticationInputData
ns1:AuthenticationDataFormatTypetext/ns1:AuthenticationDataFormatType
ns1:AuthenticationInputTypePassword/ns1:AuthenticationInputType
/ns1:AuthenticationInput
ns1:RequestId
ns1:AgencyIdSICdb/ns1:AgencyId
ns1:RequestIdentifierValue487897/ns1:RequestIdentifierValue
/ns1:RequestId
ns1:RequestTypeStack Retrieval/ns1:RequestType
/ns1:CancelRequestItem
/ns1:NCIPMessage

...which translates to the following voyager resttful DELETE method:

http://voyager-pooled-test.carli.illinois.edu:19913/mil/vxws/patron/189/circulationActions/requests/callslips/SICDB20020422101735%7C487897?patron_homedb=1@MILDB20020507031103

/mil/ - patron's agency

vxws/patron/189/ - patron's ID

circulationActions/requests/callslips/SICDB20020422101735 - item's agency

%7C - delimiter

487897 - RequestIdentifierValue

?patron_homedb=1@MILDB20020507031103 - patron's agency (again!)

from vufind.

Resolved: 2016-04-06 11:23 AM

from vufind.

The cancel requests functionality appears to be working correctly from tests, but it falsely reports that it was successful in canceling requests that it did not cancel.

For the four items below, two are in "In Transit- On Hold" status, and two are in "On Hold" status (aka "Available for Pickup"). These statuses should (and do) prevent the patron from canceling their request in the OPAC.

Both the "Cancel Selected Requests" and "Cancel All Requests" functions give the notice that "4 request(s) were successfully canceled" even though the 4 requests correctly remained uncanceled, and remain in the "Requested Items" list after the attempted cancel.

from vufind.

@gibsonjc, please reopen this ticket when you have the chance after the holidays. thanks!

from vufind.

@dmcmpbll can you set up a patron record with examples of requested items in states that cannot be canceled but say that they are when you use the cancel function so that @cedelis can troubleshoot? (Please provide patron info to him via email not on this Issue.)

@cedelis Since this is request-related, should examples be set up on TEST or DEVEL?

from vufind.

@gibsonjc probably TEST

from vufind.

I have a new batch of requests set up on TEST.
I will email @cedelis with the patron and item information.

from vufind.

Transferred the 2017-2018 conversation to new Issue: #293
Re-Closing this one.

from vufind.