-
Notifications
You must be signed in to change notification settings - Fork 18
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
Conversation
…2596-view-only-domain-request-page
🥳 Successfully deployed to developer sandbox za. |
🥳 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.
🥳 Successfully deployed to developer sandbox za. |
2 similar comments
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
@@ -0,0 +1,236 @@ | |||
{% load custom_filters %} |
There was a problem hiding this comment.
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
{% load custom_filters %} | ||
{% load static url_helpers %} |
There was a problem hiding this comment.
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
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
1 similar comment
🥳 Successfully deployed to developer sandbox za. |
There was a problem hiding this 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.
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
Ticket
Resolves #2596
Changes
Context for reviewers
Notes
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:
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
Ensured code standards are met (Original Developer)
Validated user-facing changes (if applicable)
As a code reviewer, I have
Reviewed, tested, and left feedback about the changes
Ensured code standards are met (Code reviewer)
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)
(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
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)
(Rarely needed) Tested as both an analyst and applicant user
Screenshots