-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: Add payment exemption status to Slack notifications #2251
Conversation
@@ -1,10 +1,10 @@ | |||
import supertest from "supertest"; | |||
import app from "../server"; | |||
import { createScheduledEvent } from "../hasura/metadata"; | |||
import app from "../../../server"; |
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.
If the new API structure leads to a lot of long/messy relative import paths we could look at resolving this with path aliases - https://blog.logrocket.com/using-path-aliases-cleaner-react-typescript-imports/
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.
ChatGPT generated this for me based on the Zod schema 🤖 It just needed a small tidy up after.
const sessionId = getSessionIdFromEvent(data, type); | ||
const feePayable = await getFeePayableForSession(sessionId); | ||
if (!feePayable) message += " [Exempt]"; |
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 PR ended up being more refactor than feature sorry, but this is the core of the new work.
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.
I'm a little hesitant about this (!feePayable)
logic because our most recent bug around this was actually content incorrectly setting fee payable to 0 regardless of exempt/resubmission answers. I think this change would have actually incorrectly labeled those cases [Exempt]
and we perhaps wouldn't have caught that as quick?
My hunch is something like this will be more reliable / robust:
- Regardless of
application.fee.payable
&application.fee.calculated
... - If
application.fee.exemption.disability
istrue
thenmessage += " [Exempt]"
- If
application.fee.exemption.resubmission
istrue
thenmessage += " [Resubmission]"
- ** Exemptions are asked about via a Question node so you'll want to do
Boolean({field}[0])
to evaluate
So, the only cases going forward where we'd manually look into a case are:
- Missing payment notification && submission notification does not have
[Exempt]
or[Resubmission]
suffix
Does this make sense?
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 is a really helpful comment thanks 👍 I'll go ahead and make this change.
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.
PR updated with these changes @jessicamcinchak 👌
Removed vultr server and associated DNS entries |
ef81717
to
2f33404
Compare
2f33404
to
ad08273
Compare
What does this PR do?
webhooks
directory into modular structure_old
directory temporarily - I'll pick these up very shortlyapplication.fee.payable === 0