#4688: Fix DNS record type state on Add record form

[DaisyGuti]

Ticket

Resolves #4688

Changes

• Reset the recordType Alpine variable when the Add record form opens, when a record is successfully submitted, and when Cancel is clicked.
• Added a regression test that checks the click handlers stay wired up so this bug doesn't sneak back in.

Context for reviewers

After adding a record, clicking "Add record" again was opening the form with all the body fields visible, like a type had already been picked. The dropdown itself was rendering empty (the HTML had the empty option selected), but the rest of the form was still showing.

The cause: recordType lives in the page-level Alpine x-data scope, so it stuck around between submissions. When htmx swapped in the fresh form HTML, the dropdown reset to empty but recordType kept its old value (e.g. "A"), so x-show="recordType" on the form body stayed true.

The fix is to clear recordType in the same spots we already clear showFormId — Add record click, submit-success, and Cancel — so the two pieces of state stay in sync.

Since the bug is Alpine state behavior, the test asserts the template-level click handlers are present (same pattern as the existing tab-order tests). It can't drive the JS, but it guards the hooks so a future template edit can't silently regress this.

Setup

Note: You will need env vars setup for dns hosting. View cf instance glacier env vars and our Engineering Master doc.

1. Make sure the dns_hosting waffle flag is on and the domain used for testing is enrolled in dns hosting.
2. Go to a domain overview, then DNS > DNS records
3. Click "Add record" — the dropdown should be empty with no other fields showing
4. Pick a type, fill out the form, save it
5. Click "Add record" again — the dropdown should be empty again, no form body showing until you pick a type
6. Try the same thing but click Cancel instead of saving — reopening should still start clean

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
• Update documentation in READMEs and/or onboarding guide

Ensured code standards are met (Original Developer)

• If any updated dependencies on Pipfile, also update dependencies 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)

• Follow the process for requesting a design review. If code is not user-facing, delete design reviewer checklist
• Verify new pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
• Checked keyboard navigability
• Reviewed accessibility checklist using screen reader (such as NVDA with Chrome or Voiceover with Safari), ANDI, or WAVE:
  • Tested general usability
  • Page header structure
  • Landmarks
  • Links and buttons
• Checked for errors or warnings with an a11y browser tool (such as ANDI or WAVE)

As a code reviewer, I have

Reviewed, tested, and left feedback about the changes

• Pulled this branch locally and tested it
• Verified code meets all checks above. Address any checks that are not satisfied
• Reviewed this code and left comments. Indicate if comments must be addressed before code is merged
• Checked that all code is adequately covered by tests
• Verify migrations are valid and do not conflict with existing migrations

Validated user-facing changes as a developer

Note: Multiple code reviewers can share the checklists above, a second reviewer should not make a duplicate checklist. All checks should be checked before approving, even those labeled N/A.

• New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
• Meets all designs and user flows provided by design/product
• Checked keyboard navigability
• Reviewed accessibility checklist using screen reader (such as NVDA with Chrome or Voiceover with Safari), ANDI, or WAVE:
  • Tested general usability
  • Page header structure
  • Landmarks
  • Links and buttons
• Checked for errors or warnings with an a11y browser tool (such as ANDI or WAVE)
• (Rarely needed) Tested as both an analyst and applicant user

As a designer reviewer, I have

Verified that the changes match the design intention

• Checked that the design translated visually
• Checked behavior. Comment any found issues or broken flows.
• Checked different states (empty, one, some, error)
• Checked for landmarks, page heading structure, and links

Validated user-facing changes as a designer

• Checked keyboard navigability
• Reviewed accessibility checklist using screen reader (such as NVDA with Chrome or Voiceover with Safari), ANDI, or WAVE:
  • Tested general usability
  • Page header structure
  • Landmarks
  • Links and buttons
• Checked for errors or warnings with an a11y browser tool (such as ANDI or WAVE)
• 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

References

• Code review best practices

Screenshots