Bug 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list
Summary: OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 12630
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-13 14:02 UTC by Kyle M Hall
Modified: 2015-06-04 23:32 UTC (History)
6 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 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list (1.60 KB, patch)
2014-08-27 13:08 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10883 - OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list (1.66 KB, patch)
2014-08-27 23:05 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
[PASSED QA] Bug 10883 - AllowHoldDateInFuture can let a patron jump to the top of the holds list (1.87 KB, patch)
2014-09-08 20:41 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2013-09-13 14:02:05 UTC
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 ).

http://screencast.com/t/s58QhaA8
Comment 1 Olli-Antti Kivilahti 2014-07-29 08:22:00 UTC

*** This bug has been marked as a duplicate of bug 12630 ***
Comment 2 Olli-Antti Kivilahti 2014-07-29 08:26:40 UTC
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.
Comment 3 Kyle M Hall 2014-08-27 13:08:45 UTC Comment hidden (obsolete)
Comment 4 Christopher Brannon 2014-08-27 23:04:15 UTC
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
Comment 5 Biblibre Sandboxes 2014-08-27 23:05:28 UTC
Patch tested with a sandbox, by Christopher Brannon <cbrannon@cdalibrary.org>
Comment 6 Biblibre Sandboxes 2014-08-27 23:05:50 UTC Comment hidden (obsolete)
Comment 7 Katrin Fischer 2014-09-08 20:41:18 UTC
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.
Comment 8 Tomás Cohen Arazi 2014-09-18 00:16:00 UTC
Patch pushed to master.

Thanks Kyle!