Ticket #2332: Display action needed reason email in django admin

zandercymatics commented 1 week ago

Ticket

Resolves #2332

Changes

Displays what auto-generated email would be sent to the submitter under the "show details" button when adding an action needed reason
Adds a field called "action_needed_reason_email" to facilitate this. We're going to need something like this anyway for a follow on ticket that allows us to edit these emails.
[Tradeoff] The "Show more" field is no longer hidden when there is not a changelog. Instead, we just display "No changelog found". The complexity of incorporating that mechanic (when considering that we now track two fields - the changelog AND the email) doesn't make much sense. See older commits for what that looked like. This also follows our conventions elsewhere.

Context for reviewers

This PR shows the email content of the action needed field under the action needed reason field, see design. This means that we had to tweak how that button works slightly. As we are now "tracking" two fields, we just display that no content is found (rather than directly hiding) the show more button.

As well, some minor changes had to be made to accommodate for this field. The architecture is slowly moving towards support for editing emails in the future. Worth noting that Django doesn't support readonly textfields by default (it just displays the entire field as a massive block of text).

Setup

Go to /admin
Go to domain request and select a record
If its not already, put the record in the status "Action needed" and (optionally) add an action needed reason
Save the record
Add an action needed reason (note: you do not need to save)
Click the show details button
Note the email content
With the show details tab open, change the action needed reason again. The content should update dynamically - reflecting what is set for that field

Note that steps 3-6 can be done in any order.

Code Review Verification Steps

As the original developer, I have

Satisfied acceptance criteria and met development standards

[ ] Met the acceptance criteria, or will meet them in a subsequent PR
[ ] Created/modified automated tests
[ ] Added at least 2 developers as PR reviewers (only 1 will need to approve)
[ ] Messaged on Slack or in standup to notify the team that a PR is ready for review
[ ] Changes to “how we do things” are documented in READMEs and or onboarding guide
[ ] If any model was updated to modify/add/delete columns, makemigrations was ran and the associated migrations file has been commited.

Ensured code standards are met (Original Developer)

[ ] All new functions and methods are commented using plain language
[ ] Did dependency updates in Pipfile also get changed in requirements.txt?
[ ] Interactions with external systems are wrapped in try/except
[ ] Error handling exists for unusual or missing values

Validated user-facing changes (if applicable)

[ ] New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
[ ] Checked keyboard navigability
[ ] Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
[ ] Add at least 1 designer as PR reviewer

As a code reviewer, I have

Reviewed, tested, and left feedback about the changes

[ ] Pulled this branch locally and tested it
[ ] Reviewed this code and left comments
[ ] Checked that all code is adequately covered by tests
[ ] Made it clear which comments need to be addressed before this work is merged
[ ] If any model was updated to modify/add/delete columns, makemigrations was ran and the associated migrations file has been commited.

Ensured code standards are met (Code reviewer)

[ ] All new functions and methods are commented using plain language
[ ] Interactions with external systems are wrapped in try/except
[ ] Error handling exists for unusual or missing values
[ ] (Rarely needed) Did dependency updates in Pipfile also get changed in requirements.txt?

Validated user-facing changes as a developer

[ ] New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
[ ] Checked keyboard navigability
[ ] Meets all designs and user flows provided by design/product
[ ] Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
[ ] Tested with multiple browsers, the suggestion is to use ones that the developer didn't (check off which ones were used)
- [ ] Chrome
- [ ] Microsoft Edge
- [ ] FireFox
- [ ] Safari
[ ] (Rarely needed) Tested as both an analyst and applicant user

Note: Multiple code reviewers can share the checklists above, a second reviewers should not make a duplicate checklist

As a designer reviewer, I have

Verified that the changes match the design intention

[ ] Checked that the design translated visually
[ ] Checked behavior
[ ] Checked different states (empty, one, some, error)
[ ] Checked for landmarks, page heading structure, and links
[ ] Tried to break the intended flow

Validated user-facing changes as a designer

[ ] Checked keyboard navigability
[ ] Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
[ ] Tested with multiple browsers (check off which ones were used)
- [ ] Chrome
- [ ] Microsoft Edge
- [ ] FireFox
- [ ] Safari
[ ] (Rarely needed) Tested as both an analyst and applicant user