Permission Seeding

I was just thinking about this same issue yesterday. I've not committed anything to code, but was wondering about using a migration file to create the new row in the permissions table.

Its just code in the migrations, there is an up method, whats to stop there being a Permission::create('edit widgets') statement in there?

@snapey that's what I do. If I have settings that need to be in the app, I put them in migrations.

The other option of course is seeding, but then you have to write logic to see if it's already in the database since it will just keep adding and adding anytime the seeds are run and I only wanted them to run once, so went with the migration route which works great.

I personally have all my permissions and roles in a config file that simply says:

• This app knows these permissions (view-user, create-user, etc.)
• This app knows these roles (admin, developer, financial, etc.)
• This role has this permissions

I've made an artisan command that reads this config file and 'syncs' this with the database. It creates new roles if they are added, it removes them when necessary. And the same with permissions and the link between the permission and the role.

This way I have my permissions and roles in version control and I just run the command with each deployment.

Note that in this situation the truth is always in my config file. So I do not have an interface where you can manage permissions per role. If you do want an interface where you can manage permissions this solution won't work because every time you do a new deployment the changes you made through the interface will be overwritten with the state in the config file.

Hmm, interesting. I never thought about using migrations for this. The only thing that bothers me about it is I'd prefer to keep migrations limited to schema changes, but I guess technically that could work.

I really was leaning towards the config method, where you have an array of permissions, and you have an artisan command that would read the list of permissions and create them if they don't exist. But then that's just the same thing as a seeder. It would look something like this:

$permissions = [
    'admin.dashboard.view'      => 'View Admin Dashboard',
    'admin.roles.view'          => 'View Roles',
    'admin.roles.create'        => 'Create Role',
    'admin.roles.edit'          => 'Edit Role',
    'admin.roles.delete'        => 'Delete Role',
    'admin.permissions.view'    => 'View Permissions',
    'admin.permissions.create'  => 'Create Permission',
    'admin.permissions.edit'    => 'Edit Permission',
    'admin.permissions.delete'  => 'Delete Permission',
    'admin.workflows.view'      => 'View Workflows',
    'admin.workflows.create'    => 'Create Workflow',
    'admin.workflows.edit'      => 'Edit Workflow',
    'admin.workflows.delete'    => 'Delete Workflow',
];

foreach ($permissions as $key => $value) {
    Permission::updateOrCreate(
        ['name' => $key],
        ['display_name' => $value]
    ]);
}

I think that's how eloquent's updateOrCreate method works... I'll need to double check that. But the idea is that it checks for the permissions existence based on the name field, the one I would use in my code, and then it will create if it doesn't exist, or update with the display name if it does exist. So this array becomes the "source of truth" in a way for all permissions, and I just need to keep this list updated and run the seeder on deployment, like this:

php artisan db:seed --class=PermissionsTableSeeder --force

So it sounds like we are all saying the same thing, it's just a matter of where you put this logic, in migrations, a seeder, or artisan command. And that's largely up to opinion. But I'm glad that I'm not the only one that's experienced this. I thought I was going crazy since I couldn't find anyone else talking about it.

@m-rk That's really interesting that you're doing roles in config as well. What do you do when a user is assigned to a role that later gets deleted out of config? Are you just doing a foreign key with cascading deletes and letting the database handle cleanup?

Yes, indeed. The reason why I went for the config file is that it is easier to see all of your permissions and which role is able to do what in one view without creating an web interface for that.

You could use whatever method works and makes the most sense for you. Personally I find the migration strategy cleaner. Just name the migrations appropriately, "insert_permissions", "change_dashboard_permission_name", etc.

This probably isn't something that will be changing often, if at all.

It would be slick if Laravel migrations had some sort of seed() method for migration, that would run code after the up/down method was called on each migration so you could just have it execute a particular seed.

Schema::create('some_table', function (Blueprint $table) {
    $table->increments('id');
    $table->timestamps();
})->seed(YourSeederClass:class);

@i960 that never happened and at this moment I don't see it happening in my application at this moment. But if a role is removed it is automatically removed from the user indeed

And if you want for example to split up an existing role into two new roles you do need a database migration to migrate the users to the new roles. But also this never happened for now. The roles are pretty clear in my applications and won't change that much over time. But I do create new permissions often.

@Cronix They do have this:

php artisan migrate:refresh --seed

But that would run all your seeds and only on a fresh migration. So yeah, I could see that as being cool to have. What would also be cool is versioned seeders in the core. I found a couple of packages that do it, but most didn't seem to be up to date, and I'd rather not pull in another package just for this one thing.

@m-rk I'm marking your suggestion as the answer, as it's the one I was kinda leaning towards anyway when I made this post. It just seems to feel the best to me. I will be keeping the UI for roles and role to permission relationships since I have some users outside of our dev team that will be managing that, but permissions will go in config since they are fairly static and directly tied to code.

@m-rk What's funny is in my situation it's the opposite. Permissions rarely change, and are only added when new features are rolled out. But roles, and their relationship to permissions are constantly changing. Our company has gone through a ton of structural changes over the past few years, so we have people moving around between departments, people within departments who temporarily change roles or need unique permissions that no other role has, or changes to what a role should be allowed to do. We have this same issue with our Active Directory groups. Things are starting to stabilize thankfully, but I have to build this app to allow frequent changes without code deployments in the future.