Database schema & key types

Seven tables back the package — the five 2.0 tables and the two assignment tables 2.1 adds, which also gives roles an owner. Table names come from table_names; column names are fixed:

Holder links are polymorphic (model_type + model_id), so any Eloquent model can hold roles and permissions — not just users. Custom morph-map aliases are stored in the pivots as they are everywhere else in Laravel.

Holder key type

key_type describes the models that hold roles and permissions — never this package’s own tables, which always keep an auto-incrementing key. It types the model_id column on the two polymorphic pivots:

Set it before you publish and run the migrations — the schema freezes at release:

PERMISSIONS_KEY_TYPE=uuid

use Illuminate\Database\Eloquent\Concerns\HasUuids;
use Illuminate\Foundation\Auth\User as Authenticatable;
use RoundlyConsulting\Permissions\Concerns\HasRoles;

class User extends Authenticatable
{
    use HasRoles;
    use HasUuids; // pairs with PERMISSIONS_KEY_TYPE=uuid
}

Unset or blank reads as bigint; an unrecognized value throws the toolkit’s InvalidConfigurationException rather than silently building bigint keys.

Scope key type

assignments.scope_key_type does the same for scope and role-owner models: it types scope_id on both assignment tables and roles.owner_id. Not set, it reads as key_type. One scope_id column holds every scope model’s key, so all your scopes share one key type. Window columns are dateTime, not timestamp — stored in UTC to the second, with no MySQL session time-zone shift and no 2038 limit.

Hard deletes by design

Roles and permissions do not use soft deletes: the unique name index would clash with soft-deleted rows, and every pivot cascades on delete — removing a role or permission removes its grants with it.