Skip to content
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

#2596 view only domain request page #2778

Merged
merged 20 commits into from
Sep 20, 2024

Conversation

zandercymatics
Copy link
Contributor

@zandercymatics zandercymatics commented Sep 18, 2024

Ticket

Resolves #2596

Changes

  • Adds a view-only page for domain request portfolios
  • Changes domain request wizard to be more flexible
  • Uses the domain request wizard for the summary display, rather than two competing implementations

Context for reviewers

Notes

  1. The "requesting entity" field right now just displays the value of portfolio. Since we haven't implemented the page yet, we don't yet have data to show for it.
  2. This PR does not yet modify the "manage" pages for portfolio
  3. A small refactor (I promise) was done to the domain request wizard to make more extensible. This shouldn't impact the non-org page, but it would be good to double check it.

Why is this PR so long?
I promise, its for a good reason! Our old "review" flow has a lot of tech debt at this point. My first crack at this was with the old implementation, and its going to get messy.

Instead, this PR now both lays the groundwork for the eventual implementation of the portfolio domain request form and implements the right page. It then uses the domain request wizard itself to generate the review page, just as it does elsewhere.

This was done here because our old approach was trying to mimic the style laid out by the domain request wizard.
However, duplicating the same code (in what would now be) 4 places separately was causing some issues.

So instead: now we generate the summary view using the same code that the request form does. This keeps everything in sync "for free" and has the added benefit of making the domain request wizard slightly more reusable.

Note: to keep this PR easier to review, I've decided not to also include this logic for the domain page. But it can be added there too.

Setup

Org view

From scratch:

  1. Enable the organization_feature and organization_requests flags
  2. Create a portfolio, and add that portfolio to a few domain requests
  3. Add yourself as an admin on that portfolio
  4. Test the different view pages and ensure they match the right state

Example portfolio on getgov-za:
Ensuring that the flags are enabled, just add yourself to portfolio CISA. Then make sure each view page looks as you'd expect it to.

Non-org view
Verify that the domain request review page (when you see the submit button for a new application) still looks and behaves the same.

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

Screenshots

Copy link

🥳 Successfully deployed to developer sandbox za.

Copy link

🥳 Successfully deployed to developer sandbox za.

This is a much better solution as we need to use this in the request experience anyway. This works towards that, but requires a bit of a refactor.
Copy link

🥳 Successfully deployed to developer sandbox za.

2 similar comments
Copy link

🥳 Successfully deployed to developer sandbox za.

Copy link

🥳 Successfully deployed to developer sandbox za.

Copy link

🥳 Successfully deployed to developer sandbox za.

@dave-kennedy-ecs dave-kennedy-ecs self-assigned this Sep 20, 2024
Copy link

🥳 Successfully deployed to developer sandbox za.

@@ -0,0 +1,236 @@
{% load custom_filters %}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a brand new file. I just copied the logic from the old domain_request_status page, and added blocks

Comment on lines +1 to +2
{% load custom_filters %}
{% load static url_helpers %}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. This is from the domain_request status page

Copy link

🥳 Successfully deployed to developer sandbox za.

@zandercymatics zandercymatics changed the title (draft) #2596 view only domain request page #2596 view only domain request page Sep 20, 2024
Copy link

🥳 Successfully deployed to developer sandbox za.

1 similar comment
Copy link

🥳 Successfully deployed to developer sandbox za.

Copy link
Contributor

@dave-kennedy-ecs dave-kennedy-ecs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed code, followed decisions made and agree with them. Some discussion with Zander over the decisions.
Good consolidation of code on summary of request.
Good decision to add a new view for readonly, as the request logic is very complicated.
Good attention to detail on the behavior of the views in requests with different states, as there are slight differences.

Reviewed requests in every state, while in portfolio "viewonly" and also in non-portfolio views where i was the request creator. Verified functionality in all views.

This one was a lot of work, and well done.

Copy link

🥳 Successfully deployed to developer sandbox za.

Copy link

🥳 Successfully deployed to developer sandbox za.

@zandercymatics zandercymatics merged commit 3036739 into main Sep 20, 2024
10 checks passed
@zandercymatics zandercymatics deleted the za/2596-view-only-domain-request-page branch September 20, 2024 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add new view only Domain Request pages
2 participants