Keep permissions and roles in sync between application and database

[arnevanhoorn]

I'm wondering what the best strategy is to keep permissions and roles used in your application in sync with what's in the database. In the docs there is a part about seeding the database but in a Laravel application in production we don't seed the database anymore. When new functionality is added (with possibly new permissions), how do we make sure these also end up in the database. One solution would be to make migrations to add permissions to the database but this doesn't seem ideal.

[drbyte]

One solution would be to make migrations to add permissions to the database

That is exactly the best approach, because migrations exist to keep the database in sync with application code.

[danFWD]

I'm glad I found this (admittedly older) thread because I am in the process of working on a local site, a staging site, and soon to be a production site. I figured a migration would be the best way to maintain permissions integrity. How would/have you gone about doing a migration for this?

I haven’t done it yet, but my plans are to create a permanent class for permissions migration, which when ran on my local machine, will save a JSON encoded version of the permissions to a file, which then gets pushed to staging. When running the migrations on staging, it reads the JSON and scans the tables to add any records that don't yet exist. Once the migration completes, it will delete the JSON file and that record from the migration table so that it runs every time there is a migration.

In fact, I feel like this should be built-in to Laravel and/or Spatie-Permissions, since it is such a standard case for any permissions-based app.

[drbyte]

It's quite simple. You can use php artisan make:migration, and then simply create whatever new roles/permissions need to be in the application. There are even findOrCreate methods for both roles and permissions to simplify things.

An example migration could be the following. Remember to import your custom models if you have them, instead of the base models:

<?php

use Spatie\Permission\Models\Permission;
use Spatie\Permission\Models\Role;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
use Spatie\Permission\PermissionRegistrar;

return new class extends Migration {
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Permission::create(['name' => 'view client history']);
        app(PermissionRegistrar::class)->forgetCachedPermissions();

        $role = Role::findOrCreate('Account Manager');
        $role->givePermissionTo('view client history');
        app(PermissionRegistrar::class)->forgetCachedPermissions();
    }
};

[danFWD]

You are right, this is an easy way to do it - if you start the project off adding roles and permissions using migrations.

When I started this project I was new to Laravel, and migrations were still a foreign concept to me, though. So one of the first things I did was create a developer tool that doubled as both an easy way to create and assign permissions to roles, but also as a quick reference as the project progressed:

When it came time to sync, I realized that each time I do it, I'll have to have a strategy to keep permissions in sync as well. So a reusable migration makes sense in this scenario.

(the PermissionRegistrar class is something I haven't seen before, looks useful)