Add supported_methods field to EnrollmentFlow

[machikoyasuda]

closes #2287

What this PR does

• Note: This PR currently does not add any checks throughout the app to check if a flow is supported in the in-person or digital apps.
• Adds https://pypi.org/project/django-multiselectfield/ package
• Adds supported_enrollment_methods field to EnrollmentFlow, as radio buttons that can be both selected
• The default for a new flow is having both selected: http://localhost:11369/admin/core/enrollmentflow/add/
• Updates local fixtures: All existing enrollment flows are supported both digitally and in-person, adds a sample In-Person Only and Digital Only --- but does not add those flows to CST.
• Add spec

[machikoyasuda]

Not sure why both Pytest and Cypress tests are failing here. Both suites pass for me locally. 🤨

[github-actions]

Coverage report

Click to see where and how coverage changed

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

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

[machikoyasuda]

@angela-tran and I learnt something new today:

A GitHub repo for a PyPI package might not reflect the latest release! The release page for https://github.com/goinnn/django-multiselectfield shows that the latest version is v0.1.12. But we noticed that when I had installed django-multiselectfield with the command, pip install django-multiselectfield, version 0.1.13 was installed -- and, I didn't get any failing testes locally. So we went to the PyPI page for the package directly and saw a 0.1.13 release: https://pypi.org/project/django-multiselectfield/0.1.13/, which fixed the bug that was breaking my tests.

As a result, I simply updated the version to 0.1.13, and all the tests were fixed 🎉 No hacky fixes required.

Lesson learnt: Check both the GitHub and PyPI page for the package you are using.

[thekaveman]

This looks great!

This PR currently does not update existing enrollment flows in the fixture data, nor does it add any checks throughout the app to check if a flow is supported in the in-person or digital apps.

I think for existing fixtures e.g. in dev, test, prod -- this is fine. Since the field defines a default value, we'll be good there and the flows will be updated in the database next time they are edited.

I do think it would be worth it to update our local fixtures in this PR though, just for completeness of the data when starting from scratch. And to show a full example of how the config works together.

The other minor change, can we change the label shown to admin users for the new field to: Supported enrollment methods? This is to align more closely with @indexing's comment on the analytics side: #2245 (comment)

[machikoyasuda]

@thekaveman That makes sense. Should I set all Enrollment Flows to accept both methods?

[thekaveman]

@thekaveman That makes sense. Should I set all Enrollment Flows to accept both methods?

Let's set all our existing fixtures to both 👍

Maybe add one basic sample each of a digital only and in_person only, if that feels reasonable?

[machikoyasuda]

@thekaveman Updated all:

• Existing flows are supported by both enrollment methods
• Adds a sample Digital only and In-Person only method -- but does not add them to the CST Agency. 9b2e3f6
• Renames the field to supported_enrollment_method -- this is the cleanest way to change the display name, plus it makes for more readable code, I think. a12349b

[thekaveman]

Sorry, I just realized one more thing, but it can be left for a follow-up.

We need to actually use this field! In the views that get the list of flows for the user to select from.