Some requests display as successfully canceled when they are not actually canceled

[gibsonjc]

[Transferred this conversation from #4 into new Issue]

Dec. 22, 2017, DMC wrote:
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.

Jan. 24. 2018, JCG wrote:
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?

Jan. 24, 2018, CED wrote:
gibsonjc probably TEST

Jan. 25, 2018, DMC wrote:
I have a new batch of requests set up on TEST.
I will email cedelis with the patron and item information.

Jan. 25, 2018, DMC wrote:
...we do not want these requests to be cancelled.

For I-Share requests, once the lending library has filled the request and it is on its way to the patron (In Transit-On Hold or On Hold), we do not want the patron to be able to cancel the request or it could leave items in unknown limbo.

So, the page is working correctly in that the 4 example requests were not actually cancelled.
The thing it is doing incorrectly is that it was claiming that it did succeed in canceling the requests, when it correctly did not.

[gibsonjc]

@dmcmpbll Was this one improved or solved by the work on and Closing of #388 ?