With AllowHoldsOnDamagedItems set to "don't allow", if an undamaged item is waiting on hold for a patron, has its Damaged status set while waiting, and then is checked out to the patron, Koha thinks the item is simultaneously still held and checked out. To recreate: -Place a hold on an undamaged item -Trigger the hold -Once the item is waiting for the patron, change its status to Damaged -Check the item out to that patron In the bib, the item now shows as both waiting and checked out in the holdings table and in the Holds tab as waiting. In the patron's record, it shows as checked out and waiting. It also still shows in 'Holds awaiting pickup'.
I can confirm. We've run into this issue on more than one occasion. Would like to see this fixed ASAP.
I guess this is the case because a 'damaged' item can no longer 'fill' the hold... but it's already waiting, so already triggered the hold. Maybe it could be changed for this case. I just wonder if there could be other use cases where this behaviour could be wanted?
This bug is still valid. I have a really hard time imaging a case in which a library would want an item that's understood to be Waiting for the patron to be checked out to that patron without filling the hold. It seems a safe assumption that when an item is checked out from Waiting the hold should be completed.
It seems strange that any status should be allowed to be changed while an item is waiting. It seems that the hold status should block status editing until the item is either checked out or the triggered hold status is reverted back to the queue. I could see how maybe something that was sitting on the hold shelf waiting to be picked up could be grabbed and damaged or found damaged before checking out, but it seems that logically, the item needs to be reverted to put the patron back in the queue anyway. So, either the staff member needs to revert the hold then change the status, or applying a status should automatically revert the hold.
(In reply to Christopher Brannon from comment #4) > It seems strange that any status should be allowed to be changed while an > item is waiting. It seems that the hold status should block status editing > until the item is either checked out or the triggered hold status is > reverted back to the queue. I don't see the need for that level of restriction to be placed on the user. In the instance that brought this to my attention, staff did not note the damage to the item until after it had been captured for the hold. They wanted to allow the patron to have it but note the damage for later. Your suggestion would complicate that.
I agree with Andrew - I don't see a need to block the damage status change in that way as it doesn't affect circulation. In our libraries the status seems to be most often used for documentation of damages, so for example the user is not blamed for them on return.
(In reply to Katrin Fischer from comment #6) > I agree with Andrew - I don't see a need to block the damage status change > in that way as it doesn't affect circulation. > > In our libraries the status seems to be most often used for documentation of > damages, so for example the user is not blamed for them on return. Then perhaps if a damage status is being applied to a waiting hold, it should ask staff if the item is to continue to be on hold, or reverted back to the queue?