Permissions

Alpha notice: Filament permission method names and config keys may change between tags. Treat config/dbflow-filament.php as the integration contract.

Security: Until you set permission_checker_class, the package uses AllowAllPermissionChecker — every authenticated Filament user can access workflow pages and approve/reject tasks. Replace it before shared or production environments.

DBFlow Core executes workflows. Your application decides who may start them, approve tasks, view instances, and edit definitions. The engine validates task assignment and pending state; it does not replace Laravel authorization policies for your business domain.

Separation of concerns

Runtime actors still resolve through Core's UserResolver (config('dbflow.auth'), class from config('dbflow.auth.resolver')). Filament contracts below govern admin UX gates — not the low-level task state machine.

Filament extension points

Bind implementations via class strings in config/dbflow-filament.php (*_class keys). Prefer permission_checker_class over the legacy permission_checker callable.

PermissionChecker is the primary hook for authorization in Standard Filament UI. The other contracts focus on presentation and assignee option sourcing.

PermissionAssigneeOptionsResolver is UI-only — it does not resolve runtime assignees. Pair it with DBFlow::registerAssigneeResolver() using the same string key for each approval node. See Filament UI.

Default ability strings

WorkflowFilamentPermissions passes these ability names to PermissionChecker::can() (configurable under permissions in config/dbflow-filament.php):

dbflow.tasks.view          — My Tasks navigation and page access
dbflow.tasks.approve
dbflow.tasks.reject
dbflow.workflow_instances.view
dbflow.workflow_instances.view_any
dbflow.definitions.view
dbflow.definitions.create
dbflow.definitions.update
dbflow.definitions.delete
dbflow.definitions.validate
dbflow.definitions.publish
dbflow.definitions.disable
dbflow.definitions.enable
dbflow.definitions.archive
dbflow.definitions.copy

Map them to your host permission system. Laravel Gate policies for dbflow.* are not registered automatically.

Common authorization decisions

Who can see My Tasks?

Gate access to MyWorkflowTasks through your PermissionChecker implementation and Filament panel policies. Users should only see tasks where they have a pending WorkflowTaskAssignment.

Routine approvals run here via MyWorkflowTaskTableActions → MyWorkflowTaskActionRunner.

Who can approve a task?

Core enforces:

• Task is pending
• Actor matches a pending WorkflowTaskAssignment when $actor is provided to DBFlow::approve() / reject()

Filament adds another layer: WorkflowFilamentPermissions centralizes approve/reject permission checks for My Tasks. Custom resource actions should call the same checks or delegate to My Tasks.

Who can reject?

Same path as approve. Reject strategy is chosen by the caller (DBFlow::reject() fourth argument) or Filament config (dbflow-filament.reject_strategy), not by PermissionChecker alone.

Who can view workflow instances?

Gate WorkflowInstances and ViewWorkflowInstance for operators who need audit visibility. This is separate from assignee inbox access — finance ops may view instances without holding pending tasks.

Who can edit workflow definitions?

Gate WorkflowResource for engineers or admins who may draft and publish graphs. Publishing changes affect new instances; in-flight runs keep their started version.

Implementing PermissionChecker

Implement the PermissionChecker contract from dbflowlabs/filament and set permission_checker_class in config/dbflow-filament.php. Delegate to your existing Laravel gates, roles, or team checks:

// config/dbflow-filament.php
'permission_checker_class' => \App\Support\Dbflow\Filament\AppDbflowPermissionChecker::class,

// Illustrative — implement every method required by the shipped PermissionChecker contract
final class AppDbflowPermissionChecker implements PermissionChecker
{
    public function can(mixed $user, string $ability, mixed $record = null): bool
    {
        // Example delegation:
        // return match ($ability) {
        //     'dbflow.tasks.view', 'dbflow.tasks.approve', 'dbflow.tasks.reject' => $user->can('workflow.approve'),
        //     'dbflow.workflow_instances.view', 'dbflow.workflow_instances.view_any' => $user->can('workflow.view'),
        //     default => false,
        // };
    }
}

Read the contract source in your installed dbflowlabs/filament version for the authoritative method list.

Resource actions vs My Tasks

Filament Resource Actions may start workflows from business records. Approvals should stay on My Tasks when possible so permission logic stays in one place.

If you must approve from a resource page, resolve the pending task and call DBFlow::approve() only after your own authorization check passes.

Assignee pickers and display

UserAssigneeOptionsResolver restricts definition editor choices — for example limiting pickers to users in a finance role.

UserDisplayResolver and WorkflowableLabelResolver do not grant access; they only affect labels in admin UI.

StatusBadgeMapper styles instance status badges — useful when operators scan long instance lists.

Alpha customization notes

• Permission contracts may gain new methods as Filament pages evolve.
• Demo user IDs in seeders are not production roles — replace assignee config with your resolver output.
• Pro visual builder pages will need the same host authorization mindset when you adopt dbflowlabs/filament-pro.

What's next

• Filament UI → — registration, config toggles, extension table
• Filament Resource Actions → — WorkflowFilamentPermissions guidance
• Approve and Reject → — runtime exceptions for unauthorized actions
• Workflow Timeline → — read-only audit presentation