1° with syspref AllowHoldPolicyOverride ON 2° in "Holds policy by item type" (in smart-rules.pl) with "no holds allowed" selected for an itype. 3° create an hold on an item of this itype 4° return this item 5° you have no message about the hold and the hold is not in status waiting Due to the lack of the check about the syspref during the check in.
Created attachment 58826 [details] [review] Bug 17884 - troubles with syspref AllowHoldPolicyOverride on return Test plan : 1° with syspref AllowHoldPolicyOverride O. 2° in "Holds policy by item type" (in smart-rules.pl) with "no holds allowed" selected for an itype. 3° create an hold on an item of this ityp. 4° return this ite. 5° you have no message about the hold and the hold is not in status waitin, due to the lack of the check about the syspref during the check in. 6Â with this patch you get the message about the existing hold.
Created attachment 59001 [details] [review] Bug 17884 - troubles with syspref AllowHoldPolicyOverride on return Test plan : 1° with syspref AllowHoldPolicyOverride O. 2° in "Holds policy by item type" (in smart-rules.pl) with "no holds allowed" selected for an itype. 3° create an hold on an item of this ityp. 4° return this ite. 5° you have no message about the hold and the hold is not in status waitin, due to the lack of the check about the syspref during the check in. 6Â with this patch you get the message about the existing hold. Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
You need to provide tests to cover the change made to this subroutine.
Linking some other bugs to this.
I applied this patch and tested it as follows: 1 syspref: AllowHoldPolicyOverride - Allow. 2 created an item type with No holds Allowed defined in its Hold Policy 3 created a hold on an item with the above item type 4 checked in the item 5 the hold was found and was able to be confirmed The problem was that it if you have holdable and non-holdable item types on the same record (say a library use only copy of a book that is defined by its own item type), the item with the non-holdable item type will fulfill any biblio-level hold, which essentially negates the no-holds allowed property entirely. So it works, but nor quite as I expected it. Is it possible to specify that the hold should only be fulfilled if it is an item level request (perhaps this would best be split to a different bug...)?