Next-status checkin should retarget holds that have already been captured

[Kathy Lussier]

Evergreen version: 3.1

In one of the final commits to the copy alert project, we determined that a next status applied to a copy should trump any holds that could be filled by the copy. The copy will immediately adopt that next-copy status rather than capturing an eligible hold.

Quite often, the sequence of events will probably be such that a hold is captured BEFORE the next-status copy alert is even applied to the copy. In those cases, the system will continue to attempt to fill the hold, even if the new status is unholdable.

Here is a likely series of events:

- While returning the item, the patron reports there is a problem with the item that requires mending, cleaning, etc. The item belongs to another library, meaning that staff can handle the issue themselves. Instead, they choose to add an alert for the owning library.
- Staff checks in the item, at which point a hold is captured.
- From the checkin screen, staff adds the alert that carries the next-copy status.
- The item is put into transit and arrives at the destination. When it is checked in, the staff see the alert and apply a status.

When this status is applied, I think the originally-captured hold should be retargeted in the same way that holds are retargeted when marking something damaged. Instead, the items goes on to the holds shelf.

There may be other potential hold issues that can arise when using the next-status feature that don't get addressed by this fix, but I think it will help a majority of situations where staff might be frustrated that something with a next copy status is attempting to fill a hold.

[Jeff Godin (jgodin)]

Adding context to some of the references in the first paragraph of this bug:

The "copy alert project" referenced above would be bug 1676608

The determination regarding not capturing an item is around comment 38: https://bugs.launchpad.net/evergreen/+bug/1676608/comments/38