Some thoughts and tips on USER ROLES and ROLEGROUPS in DotNetNuke.  ROLES provide the fundamental means of determining who gets to see what content.  ROLEGROUPS help organize ROLES by defining collections of ROLES but...ROLEGROUPS are not as helpful as you might expect...
 
 
Review of USER ROLES
Every visitor to a DNN website is a member of one or more USER ROLES -- even if the visitor does not have an account.  The basic (default) roles are:

• HOST
  This role grants the user ADMIN role access to all portals in the DNN instance as well as administrative access to configure the entire DNN installation.  Another common term for this role is "SuperUser". 
   
• ADMIN
  This role allows a user to administate content, users and settings for a single DNN portal.  Note that HOST users have more portal control (access to more configuration settings) than a portal ADMIN.
   
• REGISTERED USERS
  Any user who has an account on a portal.  Note: The acocunt does not have to be "active" or "verified".
   
• UNAUTHENTICATED USERS
  Any user who is not currently logged in with a DNN account.  
   
• ALL USERS
  ALL USERS is the combination of UNAUTHENTICATED USERS and REGISTERED USERS. 
   
• SUBSCRIBERS
  Any user with an account that has elected to "join" this role.  The SUBSCRIBER role is a "public role" which means users are able to add or remove themselves from the role at will.  Joining the role does not inherently do anything special -- it is up to a HOST or portal ADMIN to provide something special for members of this role (such as sending out newsletters or making available "subscriber-only" web pages).

When a user reaches a DNN website (before logging in), the user is assigned the "UNAUTHENTICATED USERS" role.  A couple of points to note on this are:

• In DNN 4.x all visitors are generally treated as being the same, single anonymous user.  The exception is modules that distinguish between source IP addresses (such as the USERS ONLINE module).
   
• In DNN 5.x, anonymous users may be treated differently based on (optional) preferences stored in a cookie.

When a visitor logs in with an existing account or creates a new account, the visitor ceases to be "UNAUTHENTICAED".  Put another way, a user who has been "authenticated" (logged-in) is no longer considered "un-authenticated" and is therefore no longer part of the "UNAUTHENTICATED USERS" group.
 
Beyond the default roles outlined above, portal ADMINs may create a virtually unlimited number of custom ROLES.  Such roles could be "FORUM MODERATORS", "BLOGGERS", "BASIC SUBSCRIBERS", "ELITE SUBSCRIBERS", etc.  This is a hugely useful feature and gives ADMINs a lot of flexibility in granting varying levels of access to website features and content.

 
ROLEGROUPS...A Wasted Effort?
ROLEGROUPS act as containers and allow admins to group USER ROLES together under a ROLEGROUP.  We'll look at a common use case and see why ROLEGROUPS may not (yet) be the worty addition to DNN that they should have been...
 
USE CASE:  COMPANY INTRANET
A common desire is to divide users into distinct groups.  For instance, a company intranet site might be divided into areas that reflect divisions within the company.  There are pages dedicated to the ACCOUNTING group, others for HR, some devoted to MARKETING, etc.  If custom DNN roles are created for each division and added to the appropriate employees' user accounts, the employees can easily be granted additional access to their division's intranet pages (for posting documents, updating calendars, moderating forums, etc).  This makes for simple and intuitive management of user access.
 
Grouping Roles
Suppose, however, that the DNN admin needs to go a step further and classify users not just by where they work within the company but also by job title.  You'd need to create roles such as IC ("individual contributor"), MANAGER1 (first-level manager), MANAGER2, VP, etc.  
 
But wait -- we already assigned users to "group" roles such as MARKETING and ACCOUNTING -- how do we incoporate the new "job title" roles as well?  There are several ways, actually...
 
OPTION1 -- ASSIGN MULTIPLE ROLES
The most common approach is to simply assign multiple roles to a user.  That is, a first-level accounting manager would be assigned both the MANAGER1 role and the ACCOUNTING role.  Unfortunately this is not useful in restricting content.  The default behavior in DNN 4.x is that module VIEW and EDIT permission rules are based on allow rather than require.  It's easy to include (allow) members of one or more user groups but it's difficult to require multi-group membership. (Note:  DNN 5.x includes the hugely useful "DENY" rule in its permissions.)

Example: Under DNN 4.x, let's say you have a reporting module that creates reports for view only by accounting managers.  You can set the module's VIEW permissions to allow view by the ACCOUNTING role and also to allow view by the MANAGER1 role but there's no option to require both roles.  Thus, a MANAGER1 from MARKETING could view the module just as an IC from ACCOUNTING could because they each are members of the ACCOUNTING or MANAGER1 roles.  Unless we want to rewrite every module in order to incorporate our own custom ROLE checking logic, we'll need a different solution...
 
OPTION 2 -- CREATE HYBRID ROLES
Using our example of a report module that is to be viewed ONLY by accounting managers, we could define roles based on a combination of COMPANY DIVISION and JOB ROLE.  All accounting roles could have a prefix of "ACCT".  The accounting manager level 1 role would then be "ACCT-MANAGER1".  If we gave marketing the prefix "MRKT" then a manager level 1 in marketing would be given the role "MRKT-MANAGER1".  We'd also want to give everyone in accounting a base role of "ACCT" and everyone in marketing a base role of "MRKT" -- this makes it easy to designate pages/content for various company divisions without adding each and every individual role to the "VIEW" permissions.  This works fine except that we might end up with a very long list of available security roles to work with.  That brings us to....
 
OPTION 3 -- PLACE ROLES INTO "ROLEGROUPS"
ROLEGROUPS allow DNN administrators to classify USER ROLES as being part of a designated "group".  For our "accounting manager level 1" example, we create a ROLEGROUP (such as "ACCOUNTING") and then create roles within the rolegroup (such as "MANAGER1").  Now we have a clear division between roles that serve to group users (the ROLEGROUPS) and roles that serve to describe job functions (the USER ROLES within the ROLEGROUPS).  When adding permissions to pages/modules, we're able to filter the list of available user roles by role group -- this makes it much easier to manage permissions settings for sites with many roles.

Cool, right?  Well, no, actually.  It's almost cool except for one serious limitation.
  
NAMESPACES and ROLE GROUPS
This is a good example of "the one you never saw coming".  Remember our example of the "MANAGER1" role under the "ACCOUNTING" role group?  Let's go back and add our "MANAGER1" from the marketing department.  We create a new role group "MARKETING", then......crud.  We discover that DNN will not let us create "MANAGER1" under "MARKETING" because there is an existing role called "MANAGER1" (under "ACCOUNTING").  It turns out that a role group does not act as a unique namespace for the roles it contains.  Or, put another way, DNN totally ignores the fact that we're using role groups when we create roles.  This makes "Option 3" unworkable for our company intranet example.  
 
Despite the addition of the Role Groups feature to DNN, "Option 2" remains our best bet. 
 
 
More Bad News
Besides the fact that role names must be unique even across role groups, there are a couple of other notable limitations.  When you use the USERS->MANAGE ROLES interface to add roles to a user account, you don't get to see ROLE GROUP info at all.  This means:

• There is nothing to indicate which Roles belong to which Role Groups.  I.e., does the "MANAGER1" role belong to "ACCOUNTING" or to "MARKETING"?  You can't tell.
• You don't have the option of filtering the list of available user roles by selecting a role group (as you do when setting permissions for pages/modules).  Instead, you get all the individual role names in one big list.  Ugh!

 
...and Some Good News
This post is actually an expansion of a DotNetNuke.com forum thread response I made on 11/24/2008.  In that response, I mentioned that I was not yet aware of any third-party modules making use of the Role Groups feature.  I'm happy to report that I have discovered that the Dynamic Login module (version 2.x) from Data Springs now supports login redirection based on Role Groups.  The Dynamic Login module was already very useful in that it enabled redirection based on individual roles.  The addition of redirection based on Role Groups makes the use of Role Groups a worthwhile thing (if you need login redirection).  The Dynamic Login module offers many other great features -- the support for Role Groups (since version 2.0) was simply one feature I had previously missed.
 
Hopefully more modules will find ways of making good use of the Role Groups feature.  Without the core ability to add same-named roles under different groups, the usefulness of Role Groups will depend on how module developers decide to support them.
 
 
If you know of other third-party modules making use of User Groups or of other ways to leverage User Groups with the core DNN feature set, please comment below.