Use of the normal users table vs a dedicated one?

[edgrosvenor]

In most cases, I don't want to have a dedicated users table for administrators. I already have roles and something akin to an is_admin column in my regular old users table. Having skimmed the code it looks like just using the standard Laravel users table is a trivial matter and I'm sure it'll take me next to no time to get it set up. I guess I'm just wondering whether it would be worth making the User model a configuration setting so that it's truly trivial for anyone that doesn't want a separate table of users. Or, at the very least, would it make sense to add instructions to the documentation on how to accomplish it.

Either way, great looking package. I plan to pull it into something I'm working on right now (and hack away until my existing admin users can use it) and can't wait to see it in action!

[Wulfheart]

Definitely second this. In my use-case I would like to call a method isAdmin() on my user model. Maybe this can be achieved through a trait or an interface?

[danharrin]

Hi! Thanks for the suggestion.

I'm open to making the users table configurable. However, and I probably didn't make this clear enough in the docs, the is_admin property is used to differentiate between normal Filament users and Filament admins, who have "root" access everywhere and can manage other users.

I could implement checks like isFilamentUser() and isFilamentAdmin() if you wish?

[iksaku]

Another way to tackle this, as mentioned in Discord by @ryangjchandler, is to migrate to use Laravel Gates and Policies instead of using filament specific DB tables and models. This is the way that Nova handles their CMS access.

If implemented, it will mean a breaking change, and maybe most of us could just accept it as a v1.1 or v1.2.

Any other ideas?

[gavinhewitt]

@iksaku Which Discord is that? Is there a dedicated Filament Discord?

[iksaku]

We're on the Livewire discord, under the #filament channel

[danharrin]

Hey @edgrosvenor @Wulfheart @iksaku. I've opened #72 with support for this feature. Would be great if you could review, thanks!

[danharrin]

Sure!

[iksaku]

#72 is a good step forward, but the need for Policies is what I'd rather use, that way I can let users access different resources based on special roles/permissions.

Still, I can see so much great stuff coming from you all!

[ryangjchandler]

Yeah, for policies to work though, you'd need custom user support otherwise you'd need multiple policies for each user type.

[edgrosvenor]

@ryangjchandler I actually hadn't thought that whole gate thing through. It was one of those "I'll figure it out when I get there" statements. Turns out the answer was "say I'm going to do it and hopefully someone will help make it possible." I'm amazed at how quickly you guys are moving on this.

[ryangjchandler]

@edgrosvenor Me and Dan are going to pair on the gates & policies this weekend at some point so hopefully we'll have an answer for you soon!

[danharrin]

Supported from v1.3.0.

[mallardduck]

This is pretty easy to pull off. I've got a local dev space I'm playing around with filament in where I've made the User's model extend Filament's user model. Then I override the $table property to users and make sure my migration matched the default filament prefixed one.

I know this is a bit different than documented - but in my case it feels easier as I'm doing minimal customization.