Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Roles work by assigning a value to something a user can do. The Roles dont change but the behaviour for those roles does. Ultra dynamic solutions tend to be overkill. </p> <p>So perhaps you have the following roles</p> <ul> <li>Super Admin </li> <li>Support </li> <li>Admin</li> </ul> <p>You can have different Actions (This would depend on your system)</p> <ul> <li>View</li> <li>Edit</li> <li>Approve</li> </ul> <p>Etc </p> <ul> <li>Super Admin [View, Edit, Approve]</li> <li>Support [View]</li> <li>Admin [View, Edit]</li> </ul> <p>The dynamic part comes in the assignment of Actions. Doing things this way you dont care what Role someone is in but what actions they have. The Actions are the dynamic aspect in this relationship. When a request is made you will use the users Role to fetch the assigned Actions to that role (Database Driven to make modifiable)</p> <p>Incorporating this into your Database structure as "<strong><em>Role has many Actions</em></strong>", means that if things change in the future you will need to update the relationship in the database but not code. </p> <p>A database structure could look something like this, depends on your needs. </p> <ul> <li>UserRole [ID, UserName, RoleID] (If user is assigned more than one role they inherit all actions, which might be duplicated and therefore selected DISTINCT or prevent this scenario, but I believe the former provides greater flexibility without complexity and limitation. NOTE: the UserRole table could be further denormalized to make UserNames unique.)</li> <li>Role [ID, Name] </li> <li>Action [ID, Name] </li> <li>RoleAction [ID, RoleID, ActionID] (Unique Key Constraint on RoleID and ActionID)</li> </ul> <p>When a request is made, you identify the user etc <strong><em>UserName</em></strong>, Then workout which <strong><em>Role(s)</em></strong> they are in by quering the RoleAction and thereby load their associated <strong><em>Actions</em></strong></p> <p>I would use <strong><em>enums</em></strong> for your Action and Role values. This makes it easier to work with. To ensure that the Database and Code are in sink, ensure that you write a Unit Test reconcile the database values against the enum values.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload