#2769: Org Member Page - Invite A New Member - [NL]

[CocoByte]

Ticket 2769

Resolves #2769

Changes

• Added an "Add a new member" page
  • NOTE: there is no "save" functionality. The save button does "submit" the form, but the form data is merely validated, not saved to the database -- see ticket ACs for functionality that is expected for this PR)
• Updated navigation accordingly ("Add new member" button on "/Members" page goes to "Add a new member" page, the breadcrumbs in "Add a new member" page navigate back to "/Members", and the Cancel button goes back to "/Members"
• Introduces a new approach for handling radio-toggle forms that allows custom radio values (before we were limited to True/False), extensible radio choices (you can have as many radio buttons as you want now), and also lets us do custom ANDI messages (which was requested in this design).
  • NOTE: the upgrade does involve a slight refactor of our HookupYesNoListener in get-gov.js so keep an eye out for that

Context for reviewers

Setup

• Turn on Org model waffle flags
• Turn on Member waffle flags

Code Review Verification Steps

Navigate to /Members;
(Verify that the ticket ACs have been met - copied below)

• Figma design here - invite a new member

• Figma design here - invite a new member but with some radio buttons filled out

• From the "Members" page, when you click "Add a new member button" (see this Figma, top right blue button) it should open to a new page called "Add a new member"

• Have an email section that is required (see accessibility note)

• Have a radio button field for "Member access" which should correlate to a role for a member (see accessibility note)

• If a user chooses "Admin Access" conditionally display another set of radio buttons for "Admin access permissions" and vice versa for "Basic access" display "Member access + basic member permissions" radio buttons (see additional context)

• Make sure to have the "cancel" button go back to the "Members" page

• The "Invite member" button should not fully work, it should still check the form validity but does not need to create a record for User PortfolioPermissions or send an invitation to a user

• No user should be able to see this page if they do not have the proper edit permissions

• Follow best practices for error messages

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)

• Tag @dotgov-designers in this PR's Reviewers for 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
• Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)

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
• 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)
• (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
• 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

References

• Code review best practices

Screenshots

[github-actions]

🥳 Successfully deployed to developer sandbox nl.

[github-actions]

🥳 Successfully deployed to developer sandbox nl.

[zandercymatics]

Here are a couple of comments, just from looking at this briefly. Nice refactor of the radio button logic. I assume that the actual post logic is handled in that follow-on ticket right?

[github-actions]

🥳 Successfully deployed to developer sandbox nl.

[github-actions]

🥳 Successfully deployed to developer sandbox nl.

[github-actions]

🥳 Successfully deployed to developer sandbox nl.

[github-actions]

🥳 Successfully deployed to developer sandbox nl.

[zandercymatics]

Nice work. Confirmed with @CocoByte that unit tests will be handled in a follow-on PR. Note that a test is failing so fix that before merging!

[github-actions]

🥳 Successfully deployed to developer sandbox nl.