Users, Roles & Groups

The goal of this page is to explain the connection between users, roles and groups.

Users

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 interesting fields to be familiar with:

• User.roles all the “roles” a user has. For more information
• User.isActive gives your users the ability to “freeze” their account

Roles (Accounts, Admins & Custom)

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”.

If Twitter were to use frame, every Joe and Jane that uses Twitter would only have an Account role. While the CEO, Jack Dorsey, would have an Admin role (...but he'd probably have an Account role too since we know Jack uses Twitter @jack).

"You have Accounts, and Admin. Why have the User superclass? No matter what role someone has on the Twitter platform, from "root", Jack Dorsey, and to @onecooluser... all of them are Users in frame. Rationale for this design decision? Every User regardless of their role needs to login, recover their password, and a plethora of shared login logic. It just makes it straightforward.

To recap: every user is a User, however, each User can hold certain roles (Admin, Account, Sales-Team, Community-Manager, fillintheblank).

Some things to note:

• The root user will be created when you first setup frame. root has The Most Privileges, and will have have an Admin role.
• The employees of the company, like employeeguy1, will have an Admin role like root, but since you granted him these Admin privileges after he "signs up" on the platform, he'll have the Account role too (signing up in frame assigns that User an Account role automatically). It should be said that employeeguy1 should (probably) never be assigned to the AdminGroup "Root." That's nuts. Scope a shiny new AdminGroup (or create specific Admin permissions) with sane privileges, and assign as appropriate to employeeguy1. To read about how frame does permissions, go here.
• To round things out, @onecooluser never gets any other roles assigned to him... so he just has one role: Account. Again, view this role as the "customery" type of role in frame.
• This graphic doesn't describe frame's AdminGroups at all. See this wiki article for information.

Thinking About Registration

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.

Use the Force

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.