due date fields allow non-sane due dates

Bug #1016102 reported by Joseph
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

Evergreen Version 2.0.3+

On IRC bshum reports ' 3402-01-06 23:59:59-05' was an allowed due date, we may want dojo to check for unreasonable due dates before allowing them.

<bshum> '3402-01-06 23:59:59-05' for a due date. That looks almost like someone might have scanned an item barcode into a due date field? 34020 could be the prefix for items from a lib in our system.

Revision history for this message
Michael Peters (mrpeters) wrote :

Tested and confirmed in master (2506f44).

You can set a specific due date in the year 3402 and perform a checkout (technically valid, I guess) but the actual due date gets displayed as 13/31/69 10:59PM, however, which is strange.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Andrea Neiman (aneiman) wrote :

Not just a dojo thing, I was able to successfully check out an item in the web client on a 3.1.5 test system with a specific due date of 3028-04-04, which the web client happily accepted & displayed normally.

tags: added: checkout webstaffclient
removed: dojo
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

Do we want to put a cap on future checkouts? I.e. you can't set a custom due date more than 1 year in the future and control it via YAOUS?

Revision history for this message
Andrea Neiman (aneiman) wrote :

+1 to having this controlled via a relative-date YAOUS

tags: added: needsdiscussion
Zavier (zavierbanks)
Changed in evergreen:
assignee: nobody → Zavier (zavierbanks)
status: Confirmed → In Progress
Revision history for this message
Mike Rylander (mrylander) wrote :

I'm definitely in favor of a YAOUS, because some sites may legitimately use crazy-far dates to model "eternal" checkouts. I'd even lobby for having the YAOUS just control whether a confirmation dialog was displayed, rather than barring distant dates completely.

Revision history for this message
Zavier (zavierbanks) wrote :

This is a pull request. Here is the url:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=3eeac3cd4e6c8ae2fd65591a5cce7f424d764cfb

I made some minor changes, to create a maximum due date for the user.

Changed in evergreen:
status: In Progress → Confirmed
assignee: Zavier (zavierbanks) → nobody
tags: added: pullrequest
Revision history for this message
Zavier (zavierbanks) wrote :
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Zavier,

Could you please rebase this onto current master and resolve the conflict with this commit? https://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4dbb87afaa8f55fe17f9b0f791d31109eb29cc21

Removing pull request.

Thanks,

Chris

tags: removed: pullrequest
tags: added: needsrepatch
Changed in evergreen:
milestone: none → 3.5-alpha
Changed in evergreen:
milestone: 3.5-beta → 3.5.0
Zavier (zavierbanks)
tags: added: pullrequest
Revision history for this message
Zavier (zavierbanks) wrote :
Changed in evergreen:
milestone: 3.5.0 → 3.5.1
Changed in evergreen:
milestone: 3.5.1 → 3.5.2
Revision history for this message
Jason Etheridge (phasefx) wrote :

I think this blows away some of the work done with bug 1712644.

The org settings should tie into the new outOfRange function in checkout.js, and no longer needs to touch t_checkout.tt2

tags: removed: pullrequest
Changed in evergreen:
milestone: 3.5.2 → none
tags: removed: webstaffclient
tags: added: needswork
removed: needsrepatch
tags: added: circ-checkout
removed: checkout
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.