Allow a Hold request to be placed on an item not checked out

@Cate Boerema Thanks

Cate Boerema When you were testing https://folio-org.atlassian.net/browse/UIREQ-27#icft=UIREQ-27 the expected behaviour was that hold requests would be allowed for any item, irrespective of status, and it was surprising that this wasn't the case?

Yes, that's what I expected since Hold requests weren't mentioned in https://folio-org.atlassian.net/browse/UIREQ-27#icft=UIREQ-27.

If my understanding behind the intent of https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28 is correct, we want hold requests to be allowed for items with any status other than available?

Yeah, that is what the SIG has said about Holds. That said, I wouldn't be surprised if we later identify more status values for which Holds should not be permitted.

Given all of this, I am inclined to go with your option 3 above. Thanks for breaking it down, @Marc Johnson! I'll close this as Won't do.

I think I may have got confused, so I'll reflect my current understanding to see if it makes sense, alongside the options I think we have. Please let me know if these options makes sense, any feedback on how to improve my understanding or the clarity of my suggestions, welcome.

@Cate Boerema When you were testing https://folio-org.atlassian.net/browse/UIREQ-27#icft=UIREQ-27 the expected behaviour was that hold requests would be allowed for any item, irrespective of status, and it was surprising that this wasn't the case?

It was my understanding, from https://folio-org.atlassian.net/browse/UIIT-42#icft=UIIT-42 and https://folio-org.atlassian.net/browse/CIRC-39#icft=CIRC-39 that a hold request should change the item status (to `Checked out - held` in the case of a `Checked out` item), which I had interpreted to also mean that hold requests could only be made for items that had been checked out. As we didn't have other cases, I hadn't considered that we might want to take a blacklist approach (option 2 below) rather than a whitelist approach.

As @Cate Boerema suggests, testing a full implementation of https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28 would be challenging as we currently only have available and variations of checked out (so the blacklist / whitelist behaviour is the same). If my understanding behind the intent of https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28 is correct, we want hold requests to be allowed for items with any status other than available?

Assuming the understanding above is correct, I think we have three options. For all of the options, we would need need to consider the impact of introducing a new item status.

1) Change the current behaviour to not check item status for hold requests (deferring this until we implement https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28). If we did this, would we want to introduce a `Held` status, for items that are requested when available?

2) Start to implement https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28 by changing the current behaviour to reverse the check of item status to anything other than available. I believe the observable behaviour wouldn't change, as the current behaviour allows all of the other available states (since allowing multiple requests).

3) Leave the current behaviour unchanged. Acknowledging that the mechanism for this might need to be inverted when we add new states and implement https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28.

For options 1 and 2, we need a fallback item status (which could be unchanged) for when the process encounters a new status that hasn't been mapped (as we do now with `Checked out` -> `Checked out - Held`) and we allow a request to be made. We do not need this for option 2, as each new status would need to be explicitly allowed.

I suppose we could implement https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28 now if you think that makes sense, @Marc Johnson. Testing it will just be difficult until we have other status values.

Thanks for filing this @Matt Connolly. Holds and recalls need to be treated differently vis-a-vis validation which is why I filed separate stories. Recalls can only be put on items that are checked out (or a variation of checked out such as checked out - held or checked out - recalled). Holds, on the other hand, may be placed on items with other statuses such as "on order" (which we haven't implemented yet). I do have a separate story in the backlog for validation of holds but I thought it was best to wait on that until we have some additional status values outside of checked out and available before implementing. Here is that story for reference: https://folio-org.atlassian.net/browse/UIREQ-28#icft=UIREQ-28