The Big Tenants & Panels & Roles Question
I asked this in the github discussion, and read across almost all tenant and panel related topics but I still need assistance.
How does this work? I have trouble structuring the application!
I can create custom panels? Great, here is a theoretical senario:
I have 3 panels:
- Admin (Sees everything)
- Sales department (sees their things only, maybe can create teams).
- Finance department (same as Sales).
So, who is the tenant? And when the sales creates a team, what's the team for? When I create teams and switch among them, I see only "Settings" page
as the demo shows.
Whats the point of teams? What is it used for? Is it just another way of "Roles and permissions"?
What about panels? Each department has their own, but all can access each other's..
canAccessPanel doc and examples are very limited so idk.
Enough of questions, here what I need to do:
Me, the App owner. Where I keep all peoples' secrets in my DB (haha).
Corporate (Tenant, the one who subscribed to the SaaS. Can create teams aka departments, and each team have their own dashboard with their own resources).
OR, instead of department, you can say "Project", a client for our client/Tenant. Where each "project" have their own reaources based on Tenant membership.
Resources (some must be shared among panels).
I am currently working on a complex ecosystem where I will use Artisan::call along with Form builder UI to allow users (Admins or tenants) to create resources, models and migrations thought the front-end instead of the Terminal. Then assign these resources to the required Dashboard/Panel. Of course each have their own DB so this won't be an issue with data structure.
As for the Roles, it's already solved by the Shield plugin.
Now for the users, I as an admin can see ALL the users but the tenant should only see and create theirs.
The documentation of Tenancy setup for v3 is very very limited so I guess we should work on improving it.
So...how do Panels and Tenants work together?1 Reply
Panels are a set of resources. So you can have a panel for e.g. sales that see one set of resource, while the admin sees another. If both see the same set of resources, but have different permissions, one panel and policies should work best.
Tenants are something like your SaaS customers. All users that belong to one tenant share resources and don't have access to the resources of another tenant.
Now in v3 you can go and tell a panel that it belongs to a tenant model, meaning that it will automatically restrict and associate all resources in that panel to the current tenant.
As for your requirement, I'd say the SaaS customers are your tenants, as all their resources are shared between teams and users, but not other customers. Not sure how to best implement this or if filament tenancy is enough for that. Depends on what exactly those teams should be able to do or not do in your app, and how strict your tenant separation should be. You could always use another package (e.g. spatie or stancl) for more advanced tenancy.