How to Implement Multi-Tenancy with Admin View Option in FilamentPHP v3?
Hi everyone,
I'm using FilamentPHP v3 and need advice on implementing a multi-tenancy setup with the following requirements:
1. Tenant Selection:
- Users can select a tenant and only see data related to that tenant.
2. Admin View:
- Certain users (admin) can opt to stay without selecting a tenant and have a global view of all data.
Current Status:
- No external multi-tenancy packages used yet.
- Planning to implement roles for normal users vs. admin users.
Questions:
- What are my options within Filament to achieve this setup?
- How can I configure Filament to allow tenant selection while providing an admin view for users with the admin role?
Any guidance or examples would be greatly appreciated!
Thanks!
10 Replies
BTW. I implemented all of it already and it works like a charm. But I just lost the admin like view to see all records.
Maybe it’s a bad pattern. But it sounds like a lot of code duplication if I’m going to create a second panel for admin. Especially because then we have to test both places and it’s quite handy to have the admin naturally test what tenant users will see as well.
We don’t expect much customization between tenant and admin users. It’s mostly a convenient impersonate for admin users if the need to work on a specific tenant.
so if you have everything implemented where's the problem? for example you have some scopes for users. then for the admin don't use those scopes or modify them based on the users role
Sorry maybe I was unclear.
The tenancy is working fine, but in the dropdown I always have to pick a tenant and the scope is then working for that tenant. Where can I basically pick a administrator like choice to show it all.
That is the part I’m missing
can you show some code?
Filament's multi-tenancy really isn't designed to do something like this, Having a Tenant selected is an assumption made everywhere across a Tenant-aware panel.
The best solution is, perhaps unufortunately, is to have a separate admin panel without tenancy.
You can use something like Impersonate to allow an admin user to temporarily switch to a user account to see what that user will see.
Instead of implementing all the table/form configuration again on the admin panel, you can extract it out into a separate class that statically returns the configuration object, and call out to that class from both the admin panel and the user panel.
Thanks for the reply @Ross Bearman . I thought as well that the impersonate plugin could be a suitable alternative. Whether im going then with a dedicated admin and tenant panel is a matter of taste then. I was hoping not to have to extract most of it into a third class, but sounds like the most maintainable solution going forward.
Thanks for the input - I wanted to make sure that im not missing out on something obvious 🙂
@krekas code wise its the filament vanilla + tenancy. Because of that I just lost out on the fact that an admin role is still scoped to the current tenant.
I’m in the same boat. I created a second panel, but I’m reusing the same resources. Based on the panel I tweak some stuff like showing an extra tenant name column or field. Is this bad practice?
No, as long as the code is clean and understandable I'd argue it's better to reuse the resource configuration, rather than copy and paste it and have to remember to update fields on both any time something changes.
How are you implementing the reuse?
Basically like this: https://github.com/filamentphp/filament/discussions/10391#discussioncomment-7904045
GitHub
Sharing User Resources between 'Admin' and 'Owner' Roles in Filamen...
I'm working on a FilamentPHP-based admin panel with separate dashboards for 'Admin' and 'Owner' roles. I've successfully created separate resources for each role using names...
Ah, I do it by creating separate resources, but having the form/table configuration in a third class that's called by both in their respective
form() and table() methods. That way other methods and properties in the individual resources can be set separately, without having to change them dynamically based on the user's role/current panel. But there isn't much difference, just go with whichever approach provides the cleanest and most understandable code for you