When an item with a hold on it is checked in via the SCO module (web), no further processing is done which results in the hold being overlooked unless the circulation desk workflow includes a regular run of the hold reports. The least fix for this would be to add a system pref allowing for the option of auto-filling the highest priority hold on an item checked in via the SCO module. Perhaps other options allowing for various alternate workflows might be added here as well. I'm listing this as an enhancement because depending on one's workflow, this may not be a bug.
I support this request.
Maybe we need another status - that marks the item until it can be processed. If we just set it to 'Waiting' it might be hard to figure out which books need to be sorted out from the returns to go on the pickup shelf.
I'm not familiar enough with the holds logistics to comment much on the best way to handle this, but do know it has been an issue a number of times for our circulation desk. What happens is that a book with a hold on it and returned via self-check ends up checked back out to a patron other than the one who put the hold on it.
Hm, we had a similar situation with SIP - thinking about it, I think it sets holds now to 'waiting' - but haven't tested.
Adding an equivalent of HoldsNeedProcessingSIP for SCI and SCO with returns might be what's needed here.