Set request creation and expriation dates

Description

We are currently relying on discovery layer that will provide valid request creation and expiration dates but this will not always be the case. The discovery layer may send the date in the past, future or might not sent at all.

For the requestDate we should use date and time stamp for the moment we create a request so we would disregard value of request start date as it comes from the discovery layer. For the request expiration date populate it only if the discovery layer has some data

Environment

None

Potential Workaround

None

Checklist

hide

TestRail: Results

Activity

Show:

Martin Tran September 12, 2019 at 12:27 AM

  • Request expirationDate is checked to see if it's parseable into a Date object. If not, then it won't be forwarded to mod-patron.

  • Done with a minor issue of valid expiration dates from EDS being treated as invalid date and so it gets ignored.

Martin Tran September 10, 2019 at 8:40 PM

9/10 - mtran:

  1. RequestDate is optional in the edge-patron API.

  2. For both instance- and item-level requests, replace the incoming requestDate with the timestamp, and if there isn't a requestDate in the JSON request, add the new requestDate element to send to mod-patron.

  3. There isn't a need to do anything for request expiration date. The expiration date is already not required, will only be populated if the client passes in, and only returned to the client if there's a value for it (set by the client).

Magda Zacharska September 5, 2019 at 12:47 AM

Bumping up the priority to P1 because if this is not implemented before request start and end dates are removed from request form in EDS no request will be possible.

Done

Details

Assignee

Reporter

Priority

Sprint

Fix versions

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created September 4, 2019 at 7:53 PM
Updated September 16, 2019 at 4:21 PM
Resolved September 12, 2019 at 12:27 AM
TestRail: Cases
TestRail: Runs

Flag notifications