3
6 Comments

What are 'Teams' for in Saas Boilerplate frameworks? (e.g. SaaSPegasus)

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!

on April 2, 2021
  1. 2

    Agreed! In the boilerplate I've built, there are different roles each role having separate set of permissions! Rocket

  2. 2

    I don't know the frameworks you cite intimately but I need to understand approaches to authorization deeper myself.

    Suggestion:

    • Teams identify collaborators (i.e. users who work on the same objects/data).
    • Groups identify different user types (e.g. sellers v buyers)
    • Roles identify different user levels (e.g. admins v regulars)

    But this is just instinctive and there is not much more than a cigarette paper squeezed inbetween Roles & Groups for me.

    For Django:

    You may well know, but:

    • Permissions are operations (view, add, change, delete) on models (classes).

    Where admin or staff can do one or both of the following:

    1. Create groups + Assign permissions to groups + Assign users to groups.
    2. Assign permissions directly to users.

    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.

    ----

    1. 1

      Nice way to explain it.

      For RBAC have you seen any good team implementations with postgres?

      1. 1

        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

        1. 1

          Nice.

          Users can see organizations and organization members if they are themselves

          Guessing it would be similar code for a different table.

      2. 1

        I haven't looked. Should be digging into this more soon. Will let you know if anything comes up.