Closed cholly75 closed 5 months ago
Questions/comments from pre-refinement: Look at login.gov for reference. Jenna may be able to help with questions.
Utilize the USWDS sign in template as a good jumping off point.
Validation
During the account creation process, after a user has verified their email, display the sign in UI with a green alert banner:
If they started to create an account, but didn’t confirm their email and try to sign in, display the sign in UI with a red alert banner:
Note: Also need to hide the 'log in' link on the verification email sent page now that we will have the correct page to display. This is a followup from the sign up ticket.
Updated email verification sent mockup 1/15/24
Mobile
Expected Results:
Expected Results:
Part 1
Expected Results:
Part 2
Expected results:
Repeat this test, but add in a password first, followed by the email.
Repeat this test, but after the button is enabled, delete either the email or password - the Log in button should disable if both fields are not filled in.
Part 1
Expected Results:
Part 2
Expected Results:
Expected Results
*Repeat this test with various users (internal/external)
Expected Results:
Part 1
Expected Results:
Part 2
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
*Note: Need to be sure that the resend automation in Zendesk works for folks that had a temp PW sent to them prior to this release that has expired.
Expected Results:
*Note: Need to be sure that the resend automation in Zendesk works for folks that had a temp PW sent to them prior to this release that has expired.
Expected Results:
Repeat this test and do the following:
Expected Results:
Repeat this test and do the following:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Repeat some tests with different users:
Expected Results: I think this is what would happen? Need to test this
Repeat this test with different users:
Expected Results:
Things to be aware of - Users that were in a pending status prior to the release of this code will not be able to use their verification link.
Added mockups from 10011 re email verification banners on the sign in page.
Pre refinement
@ttlenard As a part of this story we have changed just slightly how maintenance mode works. When you have time, let's get together so we can show you what has changed and see if any documentation or screenshots need to be updated.
There are a few more things to consider with this story. Not sure if this handing the things below should be a separate story or included. @cholly75 @rachelschneiderman @zRogersFlexion @pixiwyn @TomElliottFlexion
1 - Practitioner changes employers. Admissions clerk goes into practitioner profile in DAWSON, ensures that they are not associated with any open cases, then changes the employer. This works fine, but we had an instance where the practitioner was logged in on their DAWSON account when the employer change occurred, and they subsequently filed an EA on a case. This filed the EA incorrectly (said Resp. instead of private). The practitioner then logged out/back in, and re-attempted. This resulted in the correct filing (EA for petitioner) but the privatePractitioner record on the case wasn't created, and the practitioner was not associated with the case (they were not listed as counsel for petitioner). Furthermore, the Practitioner didn't have access to the case documents on the case. Need to be able to gracefully handle this scenario.
2 - Another scenario to think about is when an Admissions clerk creates an account for someone (can be admitting a practitioner or adding in an eAccess email to a Petitioner). When they do this, DAWSON currently generates a temporary password for the user that is valid for 7 days. We have multiple instances per week where the user doesn't log in with the temp pw within the 7 days, and they have to email dawson support and request a new temp pw. Mike has created a Zendesk automation that will resend the user an email with a new temp PW. The Court would like to be able to let the user get a new temp PW themselves, rather than having them submit an email to dawson support. Can this be considered with this ticket?
I think we need separate stories on both of these.
UX feedback on exp2
The title font should be Source Sans Pro:
In mobile and smaller screens, I'm getting the menu in the right corner. That should not be there:
For the alert banners, is there a way to decrease the padding on the right side so that text will flow into that area? In the screenshot above, "DAWSON" should ideally be on the same line as the first and not wrap. In the mobile screenshot, there's enough space to accommodate some of the text that's wrapping.
@ttlenard @cholly75 FYI we have addressed scenario #2 that Tenille mentioned a few comments above (practitioner does not verify their account within 7 day time limit) as a part of this story. We have NOT addressed scenario #1 as a part of this story.
Thanks @zRogersFlexion. Looking forward to seeing a demo of this!
Testing Feedback:
Getting a 400 error in the following scenario:
UX feedback (on Dev)
Some testing Feedback:
@rachelschneiderman @zRogersFlexion @pixiwyn @TomElliottFlexion
Looks like the DAWSON icon is now pointing to the login page instead of the DAWSON home page. Please update.
Looks like the validation has changed for the PW. I'm now getting validation errors when I have a space in the middle of my PW. It does not do this on TEST.
Some additional comments re: the logs:
I noticed that the user email is still appearing in the user.email
column if you take the following steps.
dev
environment.stage
, and /auth/login
for the request.url
. user.email
column for the entry that shows the "bad" email in the request.body
.user.email
column. UX is fine with all of the above changes. For the alert banner, in Dawson Test, the header is 17px and the body is 16px. Please match the font sizes for this story. Thank you!
@pixiwyn @rachelschneiderman @zRogersFlexion @TomElliottFlexion
I've created a quick video of a small issue I found.
@rachelschneiderman @zRogersFlexion @pixiwyn @TomElliottFlexion
More testing feedback:
Update alert in Tenille's comment above:
Unable to complete your request Your request cannot be completed. Please try to log in. If you’re still having trouble, email dawson.support@ustaxcourt.gov.
Based off of our conversation at Standup this morning, I've added in number 6 in the above comment to mention logs.
@cholly75 For your consideration on either this story or a follow up story. This issue that is existing in production today and is still present in Dev causes so much confusion to the public users.
This has to do with the verify email link that a user receives when they change their email. If the user isn't logged in on another tab with their previous email, the user get's a 401 error. When helpdesk staff respond to tickets, and in our training materials, we have to bold/capitalize all over the place that the user must remain logged in on their other tab. Sure would be nice to not have to explain this constantly.
Steps to reproduce:
Note: If the user stays logged in to DAWSON with their old email, or if they just close the tab, then the verification button works fine and their new email is verified.
@ttlenard - this is coming as #10314
Some more testing feedback: @rachelschneiderman @pixiwyn
cc: @cholly75
Issue 1
Issue 2
Dev Environment: Create Petitioner Account page
Log in page:
IRS Environment:
Issue 3
This isn't necessarily and issue, but some more formatting questions/thoughts for the "An account has been created for you with the U.S. Tax Court" email. This is what is sent when an admissions clerk sets up an account for someone. Comments/Questions are in the screen capture
Updated account created email mock:
@rachelschneiderman @zRogersFlexion @pixiwyn
Looks like if a user has an account created for them by an admissions clerk, but they do not log in within 7 days, they are getting an incorrect error message.
Currently in Cognito, the user will get this error message that tells them that their temp PW expired:
At a minimum, we need to update the error message, ideally it would be great if the user could get a new temp PW resent to them to start the 7 day cycle again.
New alert text for expired temp password
Header: Temporary password has expired
Body: The temporary password you entered has expired. We sent an email with a new temporary password that expires in 7 days. If you don’t see it, check your spam folder. If you’re still having trouble, email dawson.support@ustaxcourt.gov.
@cholly75 @ttlenard
If an external user (petitioner/practitioner) changes their login and service email, they will receive an email that they need to click a link to verify the change. The email states the verification link will expire in 24 hours, right now that is NOT true, the link will never expire.
At some point we need a story to address the expiration of that link.
@rachelschneiderman - documented verification link behavior as #10313
As a DAWSON user, so that I can have a less confusing and better tailored sign-in process, I want to sign in to DAWSON from a DAWSON URL/domain.
Currently the DAWSON sign-in process is hosted directly on Amazon servers. This is an experiential and technical disconnect from a user experience point of view; the DAWSON link on the USTC website doesn't actually take the user to DAWSON, but a cryptic Amazon URL from which they are presented with a page with none of the DAWSON/USTC stylings and which we have very little control over the look and feel. This has also presented technical problems on occasion as seen with tickets reporting issues with jumping domains during the process and browser behavior.
To streamline this overall experience and open up avenues for customizing the DAWSON sign in process, we would like to move the front-end authentication UI to be within DAWSON itself.
This story will address the sign in process for the user.
Pre-Conditions
Acceptance Criteria
Notes
Post Deployment Tasks
TODO 10007
- Rachel (https://github.com/flexion/ef-cms/pull/10277)Test Cases
Story Definition of Ready (updated on 12/23/22)
The following criteria must be met in order for the user story to be picked up by the Flexion development team. The user story must:
Definition of Done (Updated 5-19-22)
Product Owner
UX
Engineering
test
environment if prod-like data is required. Otherwise deployed to anyexperimental
environment.staging
environment.