Ensure user is associated to a `TransitAgency` before they can access in-person enrollment views

[angela-tran]

Depends on #2295 and #2284

The in-person enrollment pages assume they are in the context of some transit agency. Therefore, we wouldn't want the user to not be associated to a transit agency and attempt to view the in-person enrollment pages.

Previously, the idea was that an admin from Cal-ITP would manually associate the user to their transit agency by adding the user to a group that is referenced by the TransitAgency.

However, we can minimize the time in which a user is transit-agency-less by automatically associating the user to a transit agency based on the domain from their email.

We don't necessarily want every user associated with the transit agency to be able to do in-person enrollment, so we need a separate group to represent having permission to do that. That is the group to which they need to be manually added by a Cal-ITP admin. If the user is not in that group yet, they will not see the part of the UI for "In-person enrollment."

Technical details

Each TransitAgency will have a reference to a Group from the Django admin site via a staff_group field. This represents being associated with the TransitAgency (i.e. "belonging to" the TransitAgency.)

They will each also have a reference to a Group via a customer_service_group field. This represents having permission to do in-person enrollment.

Implementation

Model changes

• [x] Add a staff_group field to TransitAgency which is a ForeignKey to the Group model from django.contrib.auth
  • The field can be null and can be set to blank
  • on_delete should be models.PROTECT which means if someone tries to delete the Group, they need to first go remove the reference from the TransitAgency
• [x] Add another field similar to staff_group but for customer_service_group instead
• [x] Add a sso_domain field to TransitAgency which is used to map to the user's email domain

View changes

No view changes needed. It will be very unlikely for the user to not have a transit agency, due to the automatic association using sso_domain. We're ok with the app showing some generic error screen if somehow that very unlikely situation happens.

Acceptance Criteria

• [x] Users can be associated with transit agencies
• [x] Users are automatically associated with a transit agency if their email domain matches the SSO domain for the transit agency
• [x] User sees a message when trying to access a view they are not allowed to access

[angela-tran]

Split out the permissions/access of model configuration views into a separate ticket (#2278)

This ticket is now solely focused on the permissions/access for in-person enrollment views

[angela-tran]

This ticket is really saying "make sure the user is associated to a TransitAgency upon login".

[angela-tran]

So we don't need any middleware

[angela-tran]

@thekaveman helped me reframe this ticket so that instead of reacting to the user being in a bad state, we do as much as we can to put the user in a good state from the very beginning.

I updated the description to reflect this