Set up Filament + basic user management commands

[JSn1nj4]

Accessing Filament Dashboard

Filament's default routes are:

• Dashboard URL root: default admin, but customizable via APP_DASHBOARD_ROOT in .env
• Login route: {dashboard-root}/login
• Password reset request: {dashboard-root}/password-reset/request
  • Generates a password reset URL with a token that's good for 60 minutes
  • Password reset URL loads the form every time, but the form will only accept the token once

Routes removed

The default auth routes pulled in with Auth::routes(). Since Filament has its own routes for login, logout, password resets etc., the default ones provided by Laravel are no longer needed.

The old views and controllers specifically for those actions have also been removed.

Filament customizations

Filament's color customization is built around Tailwind's palette. Registering custom colors also works similarly, just using Filament's built-in tools.

For example:

• A color scale can be regestered completely manually
• Filament can also generate a color scale for you based on hex or rgb input
• You can also register a named color for use in various places in the dashboard

Current customizations were done via the default AdminPanelProvider generated by Filament.

• A variation of HackGreenville's logo was also added for if a user prefers light mode in the dashboard.

User management commands created

Laravel 10 generates custom commands with the app: prefix by default, so these new commands have that currently. We can adjust them if preferred.

Create User command

php artisan app:user:create <email> <first_name> <last_name>

Creates a new user account with a random password. If a user matching the email address exists, log an error instead.

A Password Reset email will also be generated.

Activate/Deactivate User commands

php artisan app:user:activate <email>
php artisan app:user:deactivate <email>

Activate or deactivate an existing user account. This controls whether users can log into the admin dashboard.

Note: Newly-created accounts are activated by default.

Password Reset command

php artisan app:user:reset-password <email>

Use this to reset the user's password to a new, strong password. Will ask to confirm before performing password reset.

The user will have to reset their password next time they want to sign in.

Delete User command

php artisan app:user:delete <email>

Delete an existing user. Will ask to confirm before deleting.

Considerations

1. What other actions, if any, should trigger an email to the user? (e.g. password reset, deactivation, reactivation)
2. What actions, if any, should trigger an email to the application admin? (e.g. user activation/deactivation)

---

Closes #229

[JSn1nj4]

@zach2825 I think this was the leftover stuff from the old login system:
https://github.com/hackgvl/hackgreenville-com/tree/develop/app/Http/Controllers/Auth

The login form is still there and works...

But it just takes you to the default /home URL after logging in, which 404s

Assuming Filament doesn't need these controllers and the related views, is it alright if I prune this stuff? I only see Laravel's default auth routes.

[JSn1nj4]

Ok, I'm gonna take a break from pushing until I have all the commands done. Don't want to keep running GitHub Actions for small commits...

[JSn1nj4]

@zach2825 since this PR pairs admin commands for user management w/ installing Filament, think it useful to at least include a user index and maybe "latest users" dashboard widget, or should those be separate PRs at this point?

[zach2825]

I added my feedback as a comment because everything works, just wanted to see what you thought about some of these other things...

[bogdankharchenko]

Sorry I have not been paying much attention to this, but I like it =)

[bogdankharchenko]

@JSn1nj4 these seem to be some conflicts, can you go ahead and resolve them?

[JSn1nj4]

@bogdankharchenko handled. Thanks!

[bogdankharchenko]

@zach2825 can you also take a peek into this?

[zach2825]

@bogdankharchenko I did, and had a little feedback its all been resolved and talked about 💯 thanks ‼️

[zach2825]

Well done!

[allella]

@JSn1nj4 it looks like we're just about ready to merge.

One question, which we could address in another PR if it's worth doing. Is it possible to have the login form, or even all of the admin stuff, have routes/paths that's are not obvious and/or not publicly known.

Using /admin/login would likely attract unnecessary hammering from bots over time. I'm accustom to changing at least the login form to something that isn't obvious. Bonus points if it's a path that's defined in a .env so even people reading this repo wouldn't know where to login or where the admin exists without being invited.

As for deploying this to stage for testing, can you list any necessary or optional commands or steps?

I'm assuming to run scripts/handle-deploy-update.sh and then are there any other artisan commands or other special things to run that aren't related to users?

After that, I'm guessing the user-specific commands above, like php artisan app:user:create <email> <first_name> <last_name> would be run from the command line to add people and send them emails.

On the email side, we don't have the .env configured to actually send email.

The stage and production server runs sendmail/postfix locally to relay messages through Sendgrid. So, I think it would be pretty easy for me to edit the .env vars, like

MAIL_DRIVER=sendmail
MAIL_HOST=localhost
MAIL_PORT=25
MAIL_FROM_ADDRESS=noreply @ hackgreenville ... com
MAIL_FROM_NAME=HackGreenville Labs

Sendgrid was previously authorized to send emails on behalf of HG, but I think with the November transfer we lost some DNS records, so I just added them back. Which remains me we still need to move the DNS and transactional email system away from my control. (which is sort of bottlenecked by the HG Committee getting with RefactorGVL to get email MX setup, pass wd manager, and such)

[JSn1nj4]

@allella on customizing the admin URL, I made it configurable via APP_DASHBOARD_ROOT in .env and updated the top of the PR description to reflect this change. This value affects all auth-related routes for this admin panel: the dashboard, login, logout, password reset routes, any model CRUD resources we create later.

After a quick review, no extra setup steps should be needed. The deploy script as it currently is should result in everything being up.

For email configuration, I believe you're correct.

[JSn1nj4]

Oh, also just updated the deploy script (here cc4db3f) according to this section:
https://filamentphp.com/docs/3.x/panels/installation#caching-filament-components

[allella]

@JSn1nj4 thanks.

What do you think about adding the world "path" to the new dashboard config variable so it's more clear that it's not related to "root" permissions, but rather a root directory. Perhaps APP_DASHBOARD_ROOT_PATH

Also, how about we added this variable to the .env.example too?

[allella]

@JSn1nj4 this was merged, but I did run into a Composer error because ext-intl wasn't installed and wasn't declared in the composer.json.

Should we add ext-intl as a composer required package to possibly fail earlier in the install process during the dependency stage? It seemed like composer started doing things and only realized the extension was missing after the fact.

I haven't tried to create any users yet, but the log in path is rendering. I'll share the admin path root in the Slack.

[allella]

@JSn1nj4 the email configuration is now setup on production and I created the first account as a test.

Not that we need it right now, but are there any roles, or is every user an equal admin out of the gate?