Closed ryan-APC closed 5 years ago
Roles are all checked off for the user
Just confirming, do you mean "permissions" and "role" instead of "roles" and "user"?
There shouldn't be anything else involved. If BREAD exists, the policy will be attached to the model class defined in BREAD. Any time an action is auth-checked against an instance of that model, the policy gets checked, which (by default) only checks whether Auth::user()
's role has the necessary permission.
Can you say more about what you've done? Perhaps share a screenshot of the BREAD settings? Do you have anything custom (policy class, etc.)?
Yes, permissions (under the roles tab) are all checked off giving the user permission to access all areas of the table. I don't think there should be anything else either, I have built many things using voyager and have never had an issue.
The issue comes in when I create a new table, create the model, and add the BREAD. Then if I try and click on 'edit bread', I get the 403 error. I have nothing custom, the admin panel at the moment is almost completely a fresh install. I have even tried creating a new app and this issue is still there. Could it perhaps be something to do with my localhost setup?
This may be among the weirdest things I've experienced in my career, but it seems after changing nothing and doing the exact same thing, over the weekend all is working fine now...
I wish I could offer more insight in case somebody else experiences this issue. Thanks @fletch3555 for offering some insight!
Well I'm glad you got it working.
Just to verify, you did everything through the Voyager UI, right? No creating/modifying tables through tools like phpmyadmin, or adding bread through seeders?
I only ask because it's easy to miss a step doing stuff like that. Steps that could be resolved just by moving through the UI. For example, if you create BREAD with a seeder, it won't automatically generate permissions (since it was effectively direct to the database), but if you save that BREAD (even without changing anything), it will trigger the creation.
Correct, I was doing it through the UI in this instance. If I ever figure out what it was I will share!
Just in case anyone has the same issue. How to reproduce (I think there are more ways): 1) Create table with a capitalized name, e.g. "Offers" 2) Create a BREAD 3) View BREAD. You won't be able to use it because it says table doesn't exist (error) 4) Panic and manually rename the table to "offers" (lowercase). Also change the row in data_types. 5) Forget to edit permissions to "offers" as well. 6) Voilà
Had this same exact problem, in my case I discovered the issue was from mapping the model name in my routes. This causes the id
in VoyagerBaseController@edit
to return the entire model data instead of just the id which leads to plenty errors.
Can confirm that a bug is still present and caused by model binding for routes Route::model('attribute', \App\Models\Attribute::class); Route::model('product', \App\Models\Product::class); Route::model('category', \App\Models\Category::class);
Check the name of your models inside Voyager; make sure they match the model EXACTLY in laravel
Version information
Description
After creating a new table in the database, making the model, and adding bread, I am presented with a 403 'Sorry, you are forbidden from accessing this page.' error when attempting to browse the bread for the just created table.
Roles are all checked off for the user, so this is not the issue.
Steps To Reproduce
Steps to reproduce the behavior:
Expected behavior
Should be presented with the proper page to browse the table and add/edit etc.