-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SCC-3762 - Patron Eligibility Errors #415
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor comments. Can you share a few test patron accounts to try to get all use cases locally? (this can be done on slack)
}) | ||
|
||
// Server side redirect on ineligibility when Js is disabled | ||
// TODO: Move this to seaprate API route |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you want to move this to a separate API route?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be able to remove the jsEnabled flag from the client call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest round looks good. Some comments but I think these should be fixed:
-
When going to an EDD page, the exact reason does not come up. Shouldn't it? It does come up for the hold request form:
-
When a patron cannot place holds on either Holds or EDD, disable the form. I can still submit a request on the on-site use page and can fill out the EDD form:
-
The following is low priority so not necessary for this PR. The no-js form submission redirects to a broken result:
|
||
// Server side redirect on ineligibility when Js is disabled | ||
// TODO: Move this to seaprate API route | ||
// TODO: Parse these query params in getServerSideProps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no query params. This brings up a good point. I was a bit worried about how this was being done, but now I see the POST request is doing the eligibility check, then the redirect happens, then the page does the eligibility check again in getServerSideProps
. I don't think there's a harm in checking twice, but ideally, this would only happen once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although, I have no good suggestions but I think this is a problem you can think about and recommend solution(s) later.
error.message | ||
) | ||
|
||
return { status: 500 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a message and say it was a server issue? It seems this would be the case when the NYPL Platform eligibility endpoint is down, right?
@@ -40,7 +60,7 @@ async function handler(req: NextApiRequest, res: NextApiResponse) { | |||
// JS-Disabled functionality | |||
|
|||
// Redirect to confirmation page | |||
res.redirect( | |||
return res.redirect( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was this not redirecting without the return statement here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was but i added it for consistency after adding it elsewhere as one of Edwin's suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we combine the edd and physical hold request api routes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes but i think we should do this as a follow-up optimization ticket since it'll involve potentially refactoring the posting functions as well.
patronId: patronId.value, | ||
source: source.value, | ||
pickupLocation: pickupLocation.value, | ||
patronId: patronId?.value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What case would allow for this request to be made with undefined values for these required fields? I think the optional chaining implies that case is expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This maybe was unclear. Can you remove the optional chaining? I don't see why we would want to send a hold request that didn't have these values defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
85187f9
to
dc86933
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The updates look good but tbh I cannot test this locally. I get merge conflicts when I pull locally. I think it's because of a force push in the history. So I will approve based on the updates but will have to test on train-research-catalog
once it's deployed.
patronId: patronId.value, | ||
source: source.value, | ||
pickupLocation: pickupLocation.value, | ||
patronId: patronId?.value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This maybe was unclear. Can you remove the optional chaining? I don't see why we would want to send a hold request that didn't have these values defined.
Ticket:
This PR does the following:
How has this been tested?
Accessibility concerns or updates
Checklist: