Feat: use EligibilityVerifierSelectionForm

[angela-tran]

Closes #322

This is dependent on changes from #335

Changes in this PR:

• items listed in Django form to capture user's EligibilityVerifier selection #322
• removed hard-coded verifier selection from core/views.py and removed VerifierSessionRequired from index function in eligibility/views.py (since that is where the verifier will now be saved to the session)
• added a PO file entry for the EligibilityVerifierSelectionForm's submit button and for the selection page content title

[thekaveman]

@angela-tran I know this is still WIP, but I'm wondering if it would be possible to avoid the bulk of the changes that happened in the *.po files here? It's going to make for a more difficult merge of the eventual #338 PR.

Maybe just have this PR focus on the specific adds/changes needed for the selection page, and not all the line-number, reorganization, and timestamp changes?

[angela-tran]

@thekaveman I think that's a really good idea. I will do some rebasing and editing to make as minimal of changes to the *.po files. I think what that'll look like is just the addition of an entry for the submit button (which the Figma mockup has as saying "Continue"/"Continuar").

[angela-tran]

@thekaveman As I've been looking into the remaining work to finish out the selection form, I'm starting to feel like we should split it off into a separate issue. The remaining work is all frontend and might require bigger changes or decisions. Here are the details:

In order to get from the current state in this PR to what's in the Figma mockup, the questions to answer are:

• How should we get that paragraph under the form?
  • Currently, paragraphs from viewmodels.Page is rendered above the form. See page.html
• RadioSelect in Django 3.2 renders as <li> elements. We probably don't want that? Should we add something to page.html so that we have more granular control over how radio buttons are shown? (Django docs have an example of looping over the widgets.)
• Rendering the selection_label_description may involve adding some HTML to the display value in our choices tuple. My first step would be to try out the approach in https://stackoverflow.com/questions/2204696/setting-help-text-for-each-choice-in-a-radioselect.

[thekaveman]

@angela-tran I think you're right, a separate issue to split out the frontend work makes a lot of sense here. I have some ideas so I'll write up a starter issue and you can edit with what I miss.

For this PR, rendering the unstyled radio button list with the intended functionality is good 👍

[angela-tran]

Rebased my commits onto dev, and changed the target branch to dev

[angela-tran]

The eligibility UI test won't pass until #335 is merged in. (reverse("eligibility:start") throws an exception, so the tests can't find the "Continue" button.)

[thekaveman]

@angela-tran doh! forgot about that. #335 is done and deployed 👍

[angela-tran]

Closing and re-opening to rerun the checks

[thekaveman]

You can also re-run from the failed action page:

[thekaveman]

@angela-tran I think we can just skip the failing tests for now - we know we'll have to update them in #339 anyway.

Edit to add: I mean by using .skip() on the ones that fail now with the new pages/flow.

[angela-tran]

Thank you @thekaveman! I added .skip() to those tests.

[thekaveman]

I found out what the issue is, and if you rebase on dev again you can make the tests pass:

Since there is only 1 verifier, the eligibility:index view is forwarding directly to the eligibility:start view. This view is using the eligibility.pages.start.button msgid for the button, which still has the old "Ready to continue" value.

[thekaveman]

I'll clean up these msgids a bit more in #344 once this is merged 🙏