Bug 17884 - troubles with syspref AllowHoldPolicyOverride on return
Summary: troubles with syspref AllowHoldPolicyOverride on return
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Christophe Croullebois
QA Contact: Testopia
URL:
Keywords:
Depends on: 31169
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-11 15:49 UTC by Christophe Croullebois
Modified: 2022-07-16 11:35 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 17884 - troubles with syspref AllowHoldPolicyOverride on return (1.81 KB, patch)
2017-01-11 15:53 UTC, Fridolin Somers
Details | Diff | Splinter Review
Bug 17884 - troubles with syspref AllowHoldPolicyOverride on return (1.87 KB, patch)
2017-01-16 07:58 UTC, Claire Gravely
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Croullebois 2017-01-11 15:49:14 UTC
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.
Comment 1 Fridolin Somers 2017-01-11 15:53:30 UTC
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.
Comment 2 Claire Gravely 2017-01-16 07:58:15 UTC
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>
Comment 3 Jonathan Druart 2017-01-17 09:27:26 UTC
You need to provide tests to cover the change made to this subroutine.
Comment 4 Katrin Fischer 2017-01-18 21:01:05 UTC
Linking some other bugs to this.
Comment 5 Chris Slone 2017-05-22 19:49:26 UTC
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...)?