Filament module for any/all panels

[HomaEEE]

Hello, can I make module in filament for any panels and use spatie-permissions for access? Or need duplicate for separate panel

[mozex]

Hi! You don't need to duplicate anything - a single module can register Filament assets for as many panels as you have. The panel is inferred from the directory name between Filament/ and the asset type:

Modules/Blog/Filament/
├── Admin/
│   └── Resources/PostResource.php       → admin panel
├── Dashboard/
│   └── Widgets/StatsWidget.php          → dashboard panel
└── Customer/
    └── Pages/Profile.php                → customer panel

See the Filament docs for the full layout.

If you specifically want the same resource class to appear in more than one panel, the package maps each file to one panel (the one in its directory). The cleanest approach is a shared base class plus thin subclasses per panel:

// Modules/Blog/Support/Filament/BasePostResource.php
abstract class BasePostResource extends Resource { /* all the logic */ }

// Modules/Blog/Filament/Admin/Resources/PostResource.php
class PostResource extends BasePostResource {}

// Modules/Blog/Filament/Customer/Resources/PostResource.php
class PostResource extends BasePostResource {}

A few lines per panel, no real duplication.

Permissions

The module package doesn't get involved with access control - it works exactly like in a non-modular Filament app. You have a few options:

1. Filament Shield (recommended for most cases)

bezhansalleh/filament-shield is built on top of spatie/laravel-permission and auto-generates permissions for every resource, page, and widget - including ones inside modules. It handles per-panel permissions out of the box, which is exactly what you'd need across multiple panels. This is what I use and it works great.

2. Manual checks with spatie/laravel-permission

public static function canViewAny(): bool
{
    return auth()->user()->can('view_posts');
}

3. Policies

Drop PostPolicy in Modules/Blog/Policies/ and the policies feature auto-registers it. Inside the policy methods, call spatie's can() / hasPermissionTo(). Filament picks it up automatically.

If you need different permissions per panel, either namespace your permission names (admin.view_posts, customer.view_posts) or use Spatie's guards feature with a separate guard per panel - Shield supports both flows.

Hope that clears it up - let me know if you want a fuller example for any piece.

[HomaEEE]

but if module resources need in two panels with same functional

Modules/Blog/Filament/
├── Admin/
│   └── Resources/PostResource.php       → admin panel
├── User/
│   └── Resources/PostResource.php          → users panel

[mozex]

Yep, that's the case where the shared base class really pays off. You write the logic once in a base class outside the panel-mapped directories, and each panel gets a tiny subclass. Like this:

Modules/Blog/
├── Support/
│   └── Filament/
│       └── BasePostResource.php    ← all the real logic lives here
└── Filament/
    ├── Admin/
    │   └── Resources/PostResource.php   → extends BasePostResource
    └── User/
        └── Resources/PostResource.php   → extends BasePostResource

The base class:

namespace Modules\Blog\Support\Filament;

use Filament\Resources\Resource;
use Filament\Schemas\Schema;
use Filament\Tables\Table;
use Modules\Blog\Models\Post;

abstract class BasePostResource extends Resource
{
    protected static ?string $model = Post::class;
    protected static ?string $navigationIcon = 'heroicon-o-document-text';

    public static function form(Schema $schema): Schema { /* ... */ }
    public static function table(Table $table): Table { /* ... */ }
    public static function getPages(): array { /* ... */ }
}

The two panel resources - just one line each:

// Modules/Blog/Filament/Admin/Resources/PostResource.php
namespace Modules\Blog\Filament\Admin\Resources;

use Modules\Blog\Support\Filament\BasePostResource;

class PostResource extends BasePostResource {}

// Modules/Blog/Filament/User/Resources/PostResource.php
namespace Modules\Blog\Filament\User\Resources;

use Modules\Blog\Support\Filament\BasePostResource;

class PostResource extends BasePostResource {}

That's it - same functionality in both panels, zero logic duplication.

Important: keep the base class outside the Filament/{Panel}/ path (I put it in Support/Filament/ above). If you place it inside a panel directory, the package will try to register it as a real resource for that panel and fail because it's abstract.

If the panels need to differ slightly - different navigation group, different permission name, different query scope - just override the relevant method in the subclass:

class PostResource extends BasePostResource
{
    protected static ?string $navigationGroup = 'Content';

    public static function canViewAny(): bool
    {
        return auth()->user()->can('view_posts_user_panel');
    }
}

Bonus with Filament Shield: because each subclass is its own resource class, Shield generates separate permissions per panel automatically (something like view_any_admin::post and view_any_user::post), which is usually exactly what you want when the same resource lives in two panels with different audiences.

[HomaEEE]

And then one more question about the config files: should they have the same names as in the plugin - config/modules.php, and in it we reassign variables for the module?

[mozex]

Good question - these are two separate things, easy to mix up:

1. The package's own config: config/modules.php

This is published from the package itself with php artisan vendor:publish --tag=laravel-modules-config. It controls how the package behaves - which features are active, discovery patterns, module load order, etc. There's only one of these in your whole app, and you don't put it inside any module.

2. Per-module config files: Modules/Blog/Config/{anything}.php

These are your module's config. The filename becomes the config key - it has nothing to do with the modules.php name from the package. Pick whatever name makes sense for what's inside.

Modules/Blog/
└── Config/
    └── blog.php          → config('blog.xxx')

Modules/Shop/
└── Config/
    ├── shop.php          → config('shop.xxx')
    └── payments.php      → config('payments.xxx')

// Modules/Blog/Config/blog.php
return [
    'posts_per_page' => 15,
    'allow_comments' => true,
];

config('blog.posts_per_page'); // 15

So don't name your module config modules.php - that would collide with the package's own config and cause your values to merge into it, which isn't what you want.

Merging with Laravel's built-in configs

If you intentionally name a module config the same as a Laravel core config (e.g. Modules/Shop/Config/app.php), the package merges the two. The priority setting in config/modules.php controls which side wins on conflicts - true (default) means the module overrides, false means the application overrides. Useful when a module needs to tweak app.php, mail.php, etc. without you editing the root config file.

Full details and examples in the Configs docs.