I'm picking on SaasPegasus (https://www.saaspegasus.com/) here because it was the first 'saas boilerplate/framework' I learned of, and now I think there are a zillion others, which is great.
But I'm trying to figure out what the 'Teams' concepts is for.
And, specifically, is it the same thing as Groups? Or Roles?
Or can, and/or should, they be mixed and matched?
Presumably you can kind of make it be anything you want it to be, within reason, but I was curious why 'we' chose 'Teams' instead of 'Groups' or 'Roles', because it seems like there would be natural and significant differences, even if many of the differences are, in fact, pretty nuanced.
Part of what I want to do next is build an app, and I need different permissions for different users, or user types -- i.e. roles.
So I think back to a concept which I thought used to be pretty popular but I don't really see it anymore -- RBAC -- Role-based Access Control.
That is, tell me your role, and I'll tell you what resources you have access to, and what you can do with those resources.
Maybe most commonly I think of Wordpress -- Admin, Editor, Contributor, Subscriber -- those (I think) are the built-in Roles, not Teams, and each of those Roles has capabilities/privileges/rights.
This makes a lot of intuitive sense to me, and is the type of functionality in any type of 'off the shelf' saas boilerplate product I would want to use.
I actually already bought Laravel Spark (https://spark.laravel.com/) a year or so ago -- it uses 'Teams' also.
And I checked out a couple/few others yesterday, and they use Teams, too.
It looks like Laravel and Django (the base frameworks of the previously-referenced saas boilerplate products) have at least semi-standard-ish roles/permissions infrastructure plugins/apps available.
So maybe the idea of groups/roles/permissions is so inherent or obvious and 'built-in and available' in all these frameworks that it's not even worth talking about/highlighting (because there is no new functionality being added there)?
Thanks for any ideas!
Agreed! In the boilerplate I've built, there are different roles each role having separate set of permissions! Rocket
I don't know the frameworks you cite intimately but I need to understand approaches to authorization deeper myself.
Suggestion:
Teamsidentify collaborators (i.e. users who work on the same objects/data).Groupsidentify different user types (e.g. sellers v buyers)Rolesidentify different user levels (e.g. admins v regulars)But this is just instinctive and there
is not much more than a cigarette papersqueezed inbetweenRoles&Groupsfor me.For Django:
You may well know, but:
view,add,change,delete) on models (classes).Where
adminorstaffcan do one or both of the following:So for RBAC you could (throw the cigarette paper away and) represent a role by a group.
----
If you find a reference model I would appreciate a look.
----
Nice way to explain it.
For RBAC have you seen any good team implementations with postgres?
You might be interested in the PostGraphile starter schema (where the team equivalent is called organization)
https://github.com/graphile/starter/blob/main/%40app/db/migrations/committed/000001.sql#L1735
Nice.
Users can see organizations and organization members if they are themselves
Guessing it would be similar code for a different table.
I haven't looked. Should be digging into this more soon. Will let you know if anything comes up.