FYST-1200 Update navigation for editing income forms from final review page

[jenny-heath]

Link to pivotal/JIRA issue

• https://codeforamerica.atlassian.net/browse/FYST-1200

Is PM acceptance required? (delete one)

• Yes - don't merge until JIRA issue is accepted!

Reminder: merge main into this branch and get green tests before merging to main

What was done?

• Makes it so that clients can go from the final review page to income review to editing individual income-related forms and then back to income review and to final review
• There are 2 distinct types of cases:
  • Case 1: forms that are only accessible from income review (W2s and 1099Rs)
    These pages do not appear in the intake flow. The only way to get to them is from income review and they only lead back to income review.
  • Case 2: forms that appear in the intake flow (1099G)
    These pages appear in the intake flow are can also be accessed from income review, so there are 2 "continue" mechanisms: one to get to the next step in intake and one to get back to the review page
• Another thing to note about 1099G is that clients can add and delete them so when they get to the edit page from income review, they will first be taken to the 1099G index before returning to review
• The feature spec review_page_spec should have a comprehensive overview of all the paths in and out of editing income forms from review
• I also ended up refactoring step_through_eligibility_screener to handle all states so that I could use it in my feature spec loop; I went ahead and used it in complete_intake_spec too

How to test?

• There's really only one spec for this and it's the feature spec. I could add some controller level specs for individual actions but I figure that would be redundant. I thought a feature spec was the best fit for this because all the pieces need to work together for this feature to be useful at all (testing just i.e. that one controller action returns the correct redirect path seemed like spreading out and separating the test coverage too much)

[github-actions]

Heroku app: https://gyr-review-app-5026-b282f6b416db.herokuapp.com/
View logs: heroku logs --app gyr-review-app-5026 (optionally add --tail)

[arinchoi03]

I guess fundamentally I'm trying to understand when you'd use the ReturnToReviewConcern vs not given the unemployment_controller vs retirement_controller

[arinchoi03]

i see this in our feature specs but am unsure what this is supposed to accomplish, although the tests do break when this is removed - would love to understand what this is doing.

[arinchoi03]

this tells the spec when we want to go to / location it's supposed to go to the statefile domain (not gyr which is default?)

[arinchoi03]

can we confirm this value was successfully updated?

[jenny-heath]

we could but i don't think of this test as being the place to cover that. if they w2 page doesn't work that should be caught in the form spec. i could actually just delete this line because the point of this test is to see that clicking continue takes you to the right place?

[jenny-heath]

this is for when they click "go back" so they don't end up in the middle of the flow after coming from the review page

[arinchoi03]

🚀 thanks for going through this with me! good as long as the specs pass