Summary: | OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list | ||
---|---|---|---|
Product: | Koha | Reporter: | Kyle M Hall (khall) <kyle> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | cbrannon, gmcharlt, gwilliams, olli-antti.kivilahti, sandboxes, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | Trivial patch | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 12630 | ||
Bug Blocks: | |||
Attachments: |
Bug 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list
Bug 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list [PASSED QA] Bug 10883 - AllowHoldDateInFuture can let a patron jump to the top of the holds list |
Description
Kyle M Hall (khall)
2013-09-13 14:02:05 UTC
*** This bug has been marked as a duplicate of bug 12630 *** Sorry jumped to conclusion. This is not the same issue as bug 12630 but VERY similar. Bug 12630 is about issues after re-prioritization. This is about setting the future date to past. Created attachment 31186 [details] [review] Bug 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list If a patron is allowed to add a future date for the hold using the "Hold starts on date" field, that patron can put a date in that is in the *past* which will cause them to move to the top of the holds queue ( assuming they make the past date far enough back that it is earlier than all the other hold dates ). Test Plan: 1) Enable future holds 2) Note you can use dates in the past for "hold starts on date" 3) Note you can use dates in the past for "hold expires on date" 4) Apply this patch 5) Refresh the page 6) Note you can no longer use dates in the past for those fields The bad news is, this appears to be fixed on the OPAC side. Even in 3.14, which we did not know. So, there is no problem to fix on the OPAC. HOWEVER, it does fix the problem on the staff side, which is GOOD! Because of that, I will go ahead and sign off on this. Thanks, Kyle! Christopher Patch tested with a sandbox, by Christopher Brannon <cbrannon@cdalibrary.org> Created attachment 31215 [details] [review] Bug 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list If a patron is allowed to add a future date for the hold using the "Hold starts on date" field, that patron can put a date in that is in the *past* which will cause them to move to the top of the holds queue ( assuming they make the past date far enough back that it is earlier than all the other hold dates ). Test Plan: 1) Enable future holds 2) Note you can use dates in the past for "hold starts on date" 3) Note you can use dates in the past for "hold expires on date" 4) Apply this patch 5) Refresh the page 6) Note you can no longer use dates in the past for those fields Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Created attachment 31474 [details] [review] [PASSED QA] Bug 10883 - AllowHoldDateInFuture can let a patron jump to the top of the holds list If a patron is allowed to add a future date for the hold using the "Hold starts on date" field, that patron can put a date in that is in the *past* which will cause them to move to the top of the holds queue ( assuming they make the past date far enough back that it is earlier than all the other hold dates ). Test Plan: 1) Enable future holds 2) Note you can use dates in the past for "hold starts on date" 3) Note you can use dates in the past for "hold expires on date" 4) Apply this patch 5) Refresh the page 6) Note you can no longer use dates in the past for those fields Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Changed subject: OpacAllowHoldDateInFuture to AllowHoldDateInFuture as this fix applies to staff. Works as described, passes tests and QA script. Patch pushed to master. Thanks Kyle! |