Users, Roles & Groups
The goal of this page is to explain the connection between users, roles and groups.
The User model was designed to facilitate the login system no matter what kinda “roles” they may have in your system. The User model has some important fields to be aware of:
-
User.rolesall the “roles” a user has. See below -
User.isActivegives your users the ability to “freeze” their account
There are certainly some ideas/projects that could be very successful and never use the Admin role in frame. You’re not required to make use of it. But generally speaking, once a system has users there arises the need to “categorize” them in some way: like those with the most privileges (root) and those with least privileges (Account).
There are some important differences between what Account and Admin roles were designed for. Think of Accounts as the “customers” of a system and think of Admins as the “owners” and/or “employees”. Take a support ticket feature for example (like ZenDesk, or GetSatisfaction). Accounts create the tickets, while Admins view all “open” tickets, and reply to the customer directly.
So everyone's a User? Yep, in frame everyone is a "user"––even Admins, and Accounts (or whatever classes of Admin that you define: AdminGroups). Why? Every user regardless of their privilege level will need to login, and recover their password, and a plethora of shared login logic.
Some things to note:
- The root user will be created when you first setup
frame. This particular user has The Most Privileges. Sub-note: the root user will likely never have an Account role. It just has the Admin role––that's it... - ...but anyone, like an employee of the company, can be granted Admin privileges. Think of your sales agent who needs certain metrics from the service, and needs some limited privileges to access that data. When you grant them privileges they'll have the roles: Admin and Account in their user object.
- This leaves the last role: Account. This is easy. Anyone who signs up has the Account role. Again, you should view this role as the "customer-y" type of role. This role has the least privileges.
- This graphic doesn't describe
frame's AdminGroups. Be patient.
Can users have more than one role? Yep!
The registration feature that comes with frame won’t work for our Admin role. As it shouldn’t. Each role should be unique enough that they deserve a unique creation flow. Remember that Admins can’t register. And that makes sense, we create other Admins in the backend.
Out-of-the-box frame has one AdminGroup: root.
You will likely want to create different kinds of groups in addition to the all-powerful root AdminGroup, e.g., sales, dev-ops, customer-support, etc.
Can I use groups with Accounts? Sure. Your project might benefit by extending Accounts with an AccountGroup model. For example, if I built a message board or wiki and I wanted some Accounts to moderate other Accounts or change site content... groups would be the perfect solution. It would be a huge overkill to create a new role (and schema) for a Moderator, which is like an Account in every way, only differing by a permission.
I hope this was helpful. If you have questions or think this page should be expanded please contribute by opening an issue or updating this page.