Feat: add CalFresh option

[angela-tran]

Closes #1915 and #1918

This PR adds the radio button option for "CalFresh Cardholders" to the eligibility index. The description contains a link that opens a help modal about CalFresh Cardholder eligibility.

Screenshots

To test verifier ordering

Steps for setting up to test

From existing database

./bin/init.sh

will run migrations, including a migration that sets the initial display order for your existing verifiers.

From scratch

./bin/reset_db.sh
./bin/init.sh

will recreate your database, run migrations, and load fixtures which define the values for display_order (since fixtures are loaded after migrations).

Steps for testing

Start your local app, and log into your local admin interface to edit the order of your Eligibility verifiers by drag-and-drop.

The radio buttons on the eligibility index should be in the order you specified.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
benefits/core
admin.py
models.py
Project Total

This report was generated by python-coverage-comment-action

[angela-tran]

resolved discussion: Unexpected behavior with the ordering of benefit options

In dc62f35, I added the CalFresh eligibility type and verifier as new fixtures and set their ids by incrementing the greatest id in their respective tables. This mimics how it would work if one were to use the admin interface to add CalFresh to the Benefits app database since the id is an AutoField.

When setting the references on a transit agency, I added the CalFresh eligibility type and verifier to be second in the list assuming / hoping that somehow Django would preserve the declaration order. We want CalFresh to be the second item when the app retrieves the verifiers for the eligibility selection form.

However, launching the app locally, I see that is not the case:

The eligibility selection form queries for the options using verifiers = agency.eligibility_verifiers.filter(active=True), and the result seems to be ordered by id. We can use order_by to specify an order, but we are limited to ordering by the model's fields, i.e. the declaration order is no longer available or stored anywhere.

This makes sense because ultimately what gets put in the database are just rows in the junction tables core_transit_agency_eligibility_types and core_transit_agency_eligibility_verifiers that capture the relationship but not any ordering.

The admin interface makes it even more obvious that there's no "declaration order"; you can multi-select, but the order is clearly fixed.

I propose we add a display_order field to EligibilityVerifier (PositiveSmallIntegerField I guess?) but am also curious to hear any other ideas.

[angela-tran]

@thekaveman and I discussed #1958 (comment) and agreed that the solution must include a good user experience for editing the order.

This led to finding jrief/django-admin-sortable2, which allows for maintaining ordering on whatever models you choose and for editing that order using drag-and-drop in the Django admin site.

We are following the approach described by these sections:

• Prepare the model classes
• Make the ListView sortable

Alternatives considered

The approach described by Make stacked and tabular inlines sortable is for a one-to-many relationship and therefore not applicable to our TransitAgency and EligibilityVerifier models.

The approach described by Sortable Many-to-Many Relations with Sortable Inlines is applicable, but we decided against it because it was getting complex: we'd need to use a custom through model to add display_order to the TransitAgency<>EligibilityVerifier association, write a data migration to avoid losing any existing TransitAgency<>EligibilityVerifier associations, and add a way to retrieve display_order from the through model when getting the EligibilityVerifiers since the ordering doesn't propagate all the way through to the original models.

[angela-tran]

Re: new ordering functionality, I don't think there are any unit tests to add here since all we're doing is adding a PositiveSmallIntegerField to a model and letting django-admin-sortable2 do the rest of the logic.

[angela-tran]

Ready for re-review

[thekaveman]

Looks great, I love the graphical re-ordering capability within the Admin!