-
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
reason to denial reason #29
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #29 +/- ##
=======================================
Coverage 81.95% 81.95%
=======================================
Files 20 20
Lines 654 654
=======================================
Hits 536 536
Misses 118 118 ☔ View full report in Codecov by Sentry. |
LGTM. Branch name seems correct, as well the overall quality of the PR. |
For other renaming issues, I think it's fine for now. We can fix it when implementing |
@perryzjc the reason field is not supposed to exist where you pointed out. But this can be updated manually through the user interface. It is probably much easier than generating a custom migration to update only that single field. I mentioned in the PR description: "IMPORTANT: to reflect the changes in the denial email template (changing {reason} to {denial reason}), the EmailTemplate database needs to be either reseeded or edited manually through the web interface by an admin: just change {reason | ...} to {denial_reason | ...} in the email template. Also, the request more info email template should be changed to use {request_reason | ...} instead of {reason | ...}." |
I will merge the changes. We will just have to remember to mention that the reason->denial_reason update will have to be made manually through the UI on the actual application. |
Pivotal Tracker Link
What this PR does:
Replace the "reason" parameter with "denial_reason". Also updates the name of all relevant instance variables and attributes from "reason" to "denial_reason" to avoid confusion in the code, except in the one case where the @ reason instance variable was being used both for the denial reason and the more information request reason (not implemented yet)—here, I added a new instance variable @reason_request for the more information request in the relevant controller to pass along the information.
IMPORTANT: to reflect the changes in the denial email template (changing {reason} to {denial reason}), the EmailTemplate database needs to be either reseeded or edited manually through the web interface by an admin: just change {reason | ...} to {denial_reason | ...} in the email template. Also, the request more info email template should be changed to use {request_reason | ...} instead of {reason | ...}.
This pull request fixes|implements (pick one...) ______.
Include screenshots, videos, etc.
Who authored this PR?
@ArushC
How should this PR be tested?
Are there any complications to deploying this?
Checklist:
michael/12345-add-new-feature
Any branch name will do as long as the story ID is there. You can usegit checkout -b [new-branch-name]
)