brea11y
commented
1 year ago I would lean towards going with @TKDickson first solution under desired behaviors above. That is to displaying a "read-only address" within letters (instead of showing the editable address row) and still let them get to letters. If we know that keeping the address as editable will fail when a user attempts to edit it, I think that keeping it as editable is just going to cause confusion for a user regardless of what the error message says.
We will likely want to edit and/or remove the line of text below the address since it says that the Veteran may want to update the address if it is incorrect and we would not be giving them an option to do so. I'd like to loop @mistymg in for her recommendation on removing vs. editing that line of text.
Misty, I think we would keep that first line of text as-is, so on the screen (if we make no changes to that last sentence below the address) you would see:
Letters Downloaded documents will list your address as:
Mailing address 123 Main Street, Anywhere USA 12345
If this address is incorrect you may want to update it, but your letter will still be valid even with the incorrect address.
Review letters (button)
--
Does it make sense to update and/or remove that line of text since you wouldn't be able to update the address on this screen or within the profile area of the app?
mistymg
bischoffa
jennb33
Sparowhawk
wavelaurenrussell
timwright12
What happened?
A user who does not have access to update their profile info (edit address, phone number, etc), won't have the "contact info" menu/row/button appear in Profile.
However, if that user DOES have access to letters, we will show them the 'edit address' UI on the letters landing page.
Attempting to add/edit an address, from that point, will fail - the user will tap 'save' on the address edit screen, get a loading screen, and be dropped back on the edit address screen with no other information. In the background, we're throwing a 403 error on the /mobile/v0/user/addresses/validate call, (which is just not getting handled by the letters path.....? not sure why an error snackbar or message is failing to show)
Specs:
Desired behavior
UX team will need to figure this out. Do we try to display a "read-only address" within letters (instead of showing the editable address row?) and still let them get to letters? Do we just add some error handling after-the-fact (instead of throwing no error) when they try to edit address?
Acceptance Criteria
Bug Severity - BE SURE TO ADD THE SEVERITY LABEL
See [Bug Tracking](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/va-mobile-app/testing/VA%20Mobile%20App%20Test%20Plan.md#issue-severity) for details on severity levelsLinked to Story
Found while testing letters migration #4195 but not caused by that epic
Screen shot(s) and additional information
v1/user Authorized services for the test user:
"authorizedServices": ["appeals", "appointments", "claims", "directDepositBenefits", "disabilityRating", "lettersAndDocuments", "paymentHistory", "secureMessaging", "scheduleAppointments", "prescriptions", "preferredName", "genderIdentity"],v1/user available services for the test user:
"availableServices": ["appeals", "appointments", "claims", "directDepositBenefits", "disabilityRating", "lettersAndDocuments", "militaryServiceHistory", "paymentHistory", "userProfileUpdate", "secureMessaging", "scheduleAppointments", "prescriptions", "preferredName", "genderIdentity"]403 error returning on the /mobile/v0/user/addresses/validate call: { "errors": [{ "title": "Forbidden", "detail": "User does not have access to the requested resource", "code": "403", "status": "403" }] }
Can't edit/we block off the path via profile:
Can still get to the address edit screen via Letters:
Ticket Checklist