due date fields allow non-sane due dates

Bug #1016102 reported by Joseph on 2012-06-21
This bug affects 4 people
Affects Status Importance Assigned to Milestone

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.

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
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
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?

Andrea Neiman (aneiman) wrote :

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

tags: added: needsdiscussion
Zavier (zavierbanks) on 2019-09-17
Changed in evergreen:
assignee: nobody → Zavier (zavierbanks)
status: Confirmed → In Progress
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.

Zavier (zavierbanks) wrote :

This is a pull request. Here is the url:


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
Chris Sharp (chrissharp123) wrote :


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.



tags: removed: pullrequest
tags: added: needsrepatch
Changed in evergreen:
milestone: none → 3.5-alpha
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers