Feat: transit agency home dashboard

[lalver1]

Part of #2246

This PR implements overriding the default admin site so that transit agency staff see a home dashboard upon logging in:

A superuser or Cal-ITP user still sees the default Django admin site.

Another PR will implement the top right corner "user tools" panel for transit agency staff, and another PR will implement a base html template that will be extended by all templates in the in_person app.

Steps to test:

• Reset database to use local_fixtures (bin/reset_db.sh)
• Set GOOGLE_SSO_ALLOWABLE_DOMAINS, GOOGLE_SSO_STAFF_LIST, GOOGLE_SSO_SUPERUSER_LIST to appropriate values (your email and domain) in .env
• Go to localhost/admin and sign in with your email address
• Add a CST group
• Add the CST group to CST transit agency’s “staff_group” (it will ask for audience and client_id, use dummy values)
• Change your user to not superuser
• Remove Cal-ITP from your user’s chosen groups
• Add the CST group to your user’s chosen groups
• Save (will log you out)

NOTE: If you logout and need to reach the agency home dashboard page again, you can skip the steps shown above by commenting out add_staff_user_to_group(user, request) in benefits/core/admin.py. Then, when you log in again, your user will not be automatically added to the Cal-ITP group in the Google SSO prelogin hook (pre_login_user). If you don’t do this, you’ll need to reset the database again since you’ll never see the agency home dashboard page. The reason is that you will be part of Cal-ITP, but you won't be able to edit the database since you are not a superuser.

• Go to localhost/admin, verify that the agency home dashboard appears

[github-actions]

Coverage report

Click to see where and how coverage changed

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

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

[thekaveman]

This kind of makes me feel like we should have a real benefits/admin app? Aren't we sort of faking it here with everything at the top-level? Would that pose a problem? Is it better to do it this way for some reason?

[thekaveman]

This kind of makes me feel like we should have a real benefits/admin app? Aren't we sort of faking it here with everything at the top-level? Would that pose a problem? Is it better to do it this way for some reason?

@angela-tran walked me through the thinking (and docs!) on this setup, thank you 👏 🙌 Makes total sense and please disregard my comment above.

[lalver1]

Thanks for the comments @thekaveman and @angela-tran! Quick update on this PR:

• The BenefitsAdminSite's index view gets the user's transit agency (assuming a database that has been set up) and updates the session so that the template will display it
• An index template that still needs work has been added
• Update tests

[machikoyasuda]

Suggested change

	colMS
	w-100

[machikoyasuda]

This is extremely nit-picky of me:

rider’s

[lalver1]

Not at all! Fixed it in 988b5b8

[lalver1]

I think this one is ready for a review, but I still need to fix these items for sure:

• Make the Administrator header white. I could've put an inline style to make it white, but it seems there should be a better solution.
  
• Not sure if the value for STAFF_GROUP_NAME should be set in settings (as of this PR) or read as an environment variable. Actually, I'm now leaning to an environment variable since this value will depend on where the app is deployed.

[machikoyasuda]

I see Administrator as yellow:

My OS and browser are all set to Light mode.

The color is coming from here:

Where is your black color coming from? I don't see a variable set for --header-color in the dark_mode.css from Django.

---

I set my Firefox browser to Dark, and I still see a yellow header:

---

@angela-tran @thekaveman What color does the Administrator header show up for you two? And what are your browser / operating system dark/light settings?

[machikoyasuda]

Suggested change

	<p>Verify transit benefit eligibility using agency criteria and complete a rider's open-loop card enrollment.</p>
	<p>Verify transit benefit eligibility using agency criteria and complete a rider’s open-loop card enrollment.</p>

[machikoyasuda]

Just this small thing, otherwise this PR LGTM.

There are some questions about how we approach this Header section for example across all the new pages, but I think that kind of refactoring can happen later when we need it. And that for now, this is a good start.

[angela-tran]

There are some questions about how we approach this Header section for example across all the new pages, but I think that kind of refactoring can happen later when we need it.

Thanks for noting this; I think this is an important question to answer sooner than later.

@lalver1 and I talked more about his idea from #2313 (comment) when we paired on Friday, and the plan is for him to open a separate PR that extracts out a base template that all the new pages can use.

[angela-tran]

Here is the full plan: #2246 (comment)

It is the same as what @lalver1 wrote in this PR's description.

Another PR will implement the top right corner "user tools" panel for transit agency staff, and another PR will implement a base html template that will be extended by all templates in the in_person app.

[machikoyasuda]

Just wanted to leave a comment here for everyone else: This is necessary to override a Django Admin CSS style for buttons. Without this, there would be an underline on the button.

[machikoyasuda]

Just adding something I noticed here for people to see, but it doesn't need fixing or anything:

This PR made the log out area type small, and there's something funky going on with the underlines (the two links have different line heights, and there's a border-radius applied to one link). It's b/c of the way our current app CSS styles links. This is for documentation purposes only.

[lalver1]

@angela-tran and @machikoyasuda, I was looking at the other in-person eligibility tickets and I'm wondering what you think if I add one minor thing to this PR. I would make a new template called something like base-in-person.html in the in_person/templates/in_person directory that will extend admin/base.html and will have all the common elements (like {% block extrastyle %} and {% block branding %}) from agency-dashboard-index that eligibility.html, enrollment.html and the current agency-dashboard-index.html need. Then, eligibility.html, enrollment.html and agency-dashboard-index.html will extend from base-in-person.html and that'll ensure that they have the same base styling.

[lalver1]

Thanks for the feedback last week @angela-tran. The tests were failing earlier but now they are all passing so I think this one is ready for a re-review. The key changes are:

• The original description for this PR has been updated to reflect the change in scope
• A styles.css was added for admin in 51ce1fd to avoid the situation mentioned in #2313 (comment) and to clean up the styling of the home dashboard

[machikoyasuda]

Suggested change

	<h1 class="p-0 branding-title">Administrator</h1>
	<h1 class="p-0 m-0 text-white">Administrator</h1>

Adding m-0 here will vertically center the Administrator text and the logo.

[machikoyasuda]

I think this can be deleted.

[lalver1]

👍 removed it in 57b8522

[machikoyasuda]

You can also just use text-white utility class from Bootstrap so we don't have to have this one-off style. Documented here: https://getbootstrap.com/docs/5.3/utilities/colors/#colors

[machikoyasuda]

Front-end changes LGTM 👍 👍 This is a great foundation for the rest of the In Person work.

[angela-tran]

I left some comments about naming in the tests that you can commit if you agree with them.

And there is one comment that no action is needed on -- I'll create a separate ticket for it.

Nice work 👍 👍

[angela-tran]

Suggested change

	def model_SuperAgencyUser(model_User):
	def model_StaffGroupUser(model_User):

[angela-tran]

This is nitpicky, but I think we should just use True here instead of this roundabout way of setting the boolean.

There's not a specific reason to use "1" here, right? It's a little distracting because it's not how we normally set these as far as I know.

Suggested change

	return User.objects.create(is_active="1", is_staff="1")
	return User.objects.create(is_active=True, is_staff=True)

[lalver1]

Not at all, this makes sense to use True 👍 I was looking at the database and got confused because I saw True gets stored as 1, but we are working with the Django model, not the database value and we should use True for setting the boolean.

[angela-tran]

Suggested change

	model_User.is_superuser = "1"
	model_User.is_superuser = True

[angela-tran]

Suggested change

	def test_admin_override_super_agency_user(app_request, model_SuperAgencyUser):
	app_request.user = model_SuperAgencyUser
	def test_admin_override_staff_group_user(app_request, model_StaffGroupUser):
	app_request.user = model_StaffGroupUser

[angela-tran]

🚀

[machikoyasuda]

Woohoo! 🔥 🔥 🔥
Great job @lalver1 on a big PR!