I use the user table for the clients model.
protected $table = 'users';

It makes sense to separate it and make a clients table.
Is that how most people handle this?

I think what you're running into then is Laravel's default morph-map correlating the model with its table name.

You "can" override the morph mapping. One caveat I've run into with that is once I declared a custom morph map I had to manually declare "all" morph maps, not just my custom one. I never dug further to figure out how to keep "the rest" as dynamic.

I will check it out, thanks!

You've mentioned making various changes to code to make it "work". Have you also been deleting previously-assigned role/permission assignments for your users?
Because the morph class mapping is persisted in the database with each assignment.
So, if the lookup for permission access doesn't find a match in the db, access will not be granted.

Yes I am rerunning the migration:fresh --seed for each change.
erified that the morph map was added as required..

This issue stems from wanting a UserPolicy and a ClientPolicy to assign diferent permissions to the User / Client Models for some roles.
Maybe there is a way to achieve that extending the User Model

In this package's test suite we have multiple User models, extending others for various reasons, and all the tests pass. Most of the tests run multiple times in various configurations for the sake of testing various custom model scenarios.

So I'm surprised at there being a problem.

Also ... just to be clear: though a Client can extend a User, no Client "is" the same as a User: the models are distinctly separate, and have unique role/permission profiles: there's no inheritance between Users and Clients when it comes to roles/permissions .... er, well, I guess unless you were to stick both models into the same db table, in which case there could be unpredicted outcomes.
Retrieval and caching are model-specific, all dependent on Laravel's Eloquent relations.

I'm sure the problem is due to my lack of understanding.
I'll look at the test models
It sounds like I need to

• Add new class Client extends User. Looking at the tests, Admin Model extending might be the example you are talking about.
• add Policies for both.
• add a client migration table
• add enforceMorphMap to boot in AppServiceProvider
• create a guard 'client' (that I will use to add permissions) ? I'm OK with same guard at this point
• add a provider for client guard that points to the Client Model

what next to do is unclear..
What / where do I try both Models to login a user/client ?

thanks for your help!

Yes using the same table for both causes undesirable results.
I should have mentioned that I'm using Filament and Shield