Extended configuration options

[zltn]

Just installed this for a new projects and super happy how quickly I got it up and running. A couple of configuration options I miss or couldn't find:

• Re-use my existing user table vs creating a new one, believe there's already a thread for that here. This would be by far the most important one - Fixed with Ability to set up a custom users table #72
• Configure the top widgets on the dashboard. The only way I found was to publish the views (which is also not documented) - feature: added config option to show / hide default widgets #71 fixed this
• Sort the resources in the side menu found the $navigationSort property on the resource but does not seem to respond to any number.~~ Bug fixed with this commit
• be able to de-activate edit and create for some resources, ideally even per user(type) - added in 1.5
• Configure colors. I tried publishing the assets but the css is already minified. Would be great if we could use tailwind configurations for this - added in 1.5
• Edit resource behavior after saving. Right now you return to the same page, but there's no back button. Would be great to be able to configure to enter go back to the table or keep existing behavior. For the existing behavior I'd recommend adding a clear back button to the table view

[danharrin]

Hey @zltn. I've opened #72 with support for custom user tables. Would be great if you could review, thanks!

[danharrin]

Hey @zltn, I appreciate the concern but I don’t think this is a security issue? The default behaviour ensures that custom setups work out of the box, and we encourage users to override these methods to build their own setup anyway. We won’t be making the users migration optional, that would just be an extra installation step that 95% of users would not benefit from. If you’d like to remove the tables from your app, simply write a migration that deletes them. Thanks!

[zltn]

Agree on the migration, that's what I did for my use case, just wasn't sure which one of the two methods is (will be) more popular.

For the two methods above I'd strongly encourage to flip the check and only return true if the column is set and the value is true. Returning false in all other cases will still make it work out of the box but no user will be authorized by default which I'd consider safer vs making all users filament-users and admins by default by just adding the trait. Laravel's gates work similarly where the default return is void and only return true if the statement is explicitly true

[danharrin]

After discussing this with @ryangjchandler, we agree that this approach is safer, and have removed admin permissions from users by default. They will still be able to access Filament, but this feels like a good compromise between ease of use and maximum security. The docs now clearly detail how to restrict access to Filament, and the recommended approach will remain with the default filament_users table.

[zltn]

Awesome, looks like the new docs haven't been deployed yet but read through here and looks good https://github.com/laravel-filament/docs/commit/cf56887d32499ab110d34ff388c03b8b58c9b234

[danharrin]

Yeah we were having a few issues getting them to build. All fixed now, thanks!

[danharrin]

Nav sorting is fixed in 35c3751, soon to be released.

[danharrin]

Supported from v1.3.0.

[danharrin]

The widgets will be configurable when #71 is reviewed.

[danharrin]

Also supported from v1.3.0.

[danharrin]

The primary colour will be configurable in the near future through a configuration option.

[danharrin]

You may customise save behaviour by overriding the save() method on the edit page class. We may provide an option for "Save", "Save & Close" etc in the future, would that fit?

[zltn]

@danharrin just updated and running into two things that I couldn't find in the docs:

• this assumes you're using Filament's default User model + roles. I'm using a custom User model + Spatie's permission for roles. I saw there was a getFilamentRolesColumn stub so should I assume that I have to store the roles only in a column on the user model vs a separate table like Spatie does ? Would also be good to document the roles column behavior in the docs when using a custom User model

• I saw the authorization() stub on the resource but couldn't figure out how this would work on a per model base and how this would work for relationships like my example above

[zltn]

looks like I was a bit to eager, only merged in the dev branch, not main. But stil curious how the roles would work if they are not stored in the user table

[danharrin]

@zltn roles are an option only to apps that choose to have a JSON roles column, specifically for Filament, on their users table. Everything that can be done with roles can be done with policies, they just keep auth logic together with the resource and save the extra class 👍

[ryangjchandler]

@zltn To use your own permissions, I'd recommend creating a policy for your models:

class OrderPolicy
{
    use HandlesAuthorization;

    public function create(User $user, Order $order)
    {
        return $user->hasRole('name-of-role');
    }
}

[zltn]

perfect, just tested with the dev branch and works

[danharrin]

We will have support for Laravel authorisation policies soon, which will allow you to restrict edit and create access.

[danharrin]

@sbrow they should work, what have you tried that doesn't behave correctly?

[YunshuaiPeng]

Same confused. My UserPolicy delete method return false. But I can delete user still.

[danharrin]

@pys1992 is the policy registered in Laravel?

[YunshuaiPeng]

@danharrin Yes. It registered by the auto discovery behavior.
I did these steps:

1. php artisan make:policy UserPolicy --model=User create user policy.
2. Alter the delete method to return false.
3. php artisan make:filament-resource User create user resource.

Then I can see users on admin page. Finally I select a user and click delete button, user deleted.

Did I miss any steps?

[danharrin]

Ah, @pys1992 if you're using an admin account then you override all permissions automatically. Create a new user account without superuser perms.