Laravel-permission: Default guard from config/auth.php isn't picked up while doing Role::create()

[introwit]

Hi, Thank you for the amazing work you guys do to maintain such a crucial package ❤️

The Situation

• We are using the package on a non-user model. (Simplified example: On the Account model. A user has many accounts and an account belongs to a user)

• Creating the Role by doing Role::create(...)

The Problem

• The package should pick the default guard from config/auth.php to maintain the namespace. However that doesn't happen.

• The Role.php model has a static method create, hence when doing Role::create the constructor never runs. The constructor is the place responsible to pick the default guard from the auth config file. Hence the guard_name index here is always null given the constructor logic is never executed.

Not sure exactly if this is a bug, so wanted to confirm it first with you guys. I've created a fresh laravel app with the pkg and an example simple test which fails as expected because of the behaviour described above.

Let me know if I need to make a PR with any desired solution you want, happy to contribute however I can 🙂

[introwit]

UPDATE: I realised Guard::getDefaultName(static::class) does return the guard name api, then why the exception in the test 🤔

[drbyte]

When the model has no $guard_name property set (eg your Account model), it does a lookup.
To do that fallback lookup, the Guard class looks at the config/auth.php settings for valid possibilities.
It looks at the guard and its configured provider and the associated model.
Then it looks for a match between the model you're assigning for vs the provider's model.
In your case there's no match, and the guard_name property is not set on the Account model.

[introwit]

@drbyte so specifying the guard_name prop on the Account model should do it. I wonder if there are any side effects since that model has nothing to do with a guard? Looks like laravel doesn't care if any such prop exists on the model or not, so looks like should be fine?

[drbyte]

As far as I've seen, no other infrastructure looks for a guard_name property so there shouldn't be any conflict.

I agree that it may feel confusing to your dev team since as you say the model itself is kinda guard-agnostic.

A future improvement could be to have this package declare that it doesn't care about specific guards at all. But really then it doesn't even need its extensive polymorphism and would be better to be simplified (v1 of this package operated that way, and was simpler for sure).

[introwit]

yeah v1 was really simple 😄 should I close this issue? (I see that you have added a label so not sure) Will try to source dive and see if I can make a PR if it overwhelms the team again

[introwit]

thank you for the help Chris ❤️ you are too kind to quickly help out 🙂

[drbyte]

I added the label just for internal reference

[drbyte]

You might explore this PR: https://github.com/spatie/laravel-permission/pull/1384

While it got closed by the bot, it's still on my radar. And if it were merged it might solve the issue for you because it does another layer of fallback.
I'd be curious your thoughts/experience from trying it out.

[introwit]

interesting, will check it out! Thank you again ❤️