Built In System Roles:
Admins
This role cannot be deleted.
Users in this role can do anything in the site regardless of other permission settings. In other words when specifying allowed roles, it does not matter whether you check the box for this role, users in this role have permissions regardless of the settings.
Only users in this role or Role Administrators can Add/Edit/Delete roles.
Only users in this role can add users to roles.
By default, only users in this role can create users independent of site registration, this can be overridden with the Web.config/user.config setting <add key="RolesThatCanManageUsers" value="" />
Only users in this role can configure site security settings like authentication settings, ldap, password format.
Content Administrators
This role cannot be deleted.
Users in this role can view any page in the site regardless of permissions except pages with Admins as the only role with View permissions. So if you explicitely set a view/edit permission to admins only then members of Content Administrators cannot edit/view it.
Users in this role can Add/Remove Pages.
Users in this role can edit any page or module regardless of permission settings (except as above).
Users in this role can determine what other roles can View/Edit a page.
Users in this role can change site settings except security settings
Role Administrators
Users in this role can create and delete roles (except non deletable system roles) and can add/remove users from roles except the Administrators role.
Authenticated Users
This role cannot be deleted.
Users are automatically added to this role but can be removed from the role.
The purpose of this role is to make it easy to have pages where you have to be signed in to see the page but you don't want any other role permissions required on the page.
Additional Roles
You can create as many roles as you need and grant the various page and module permissions to these roles on a page by page or module by module basis to have as much granular control as you need over content management. You may create a root menu page for various departments and create roles for those departments with Page Edit and Create Child Pages permissions on a page thereby giving them edit permissions on their main page and any pages they choose to create beneath it forming a menu tree.
Permissions:
Page View
assigned by role on per page basis, enforces what pages are in the menu for the user to see
All Users, allow unathenticated users to view the page.
enforced in the page so that even if the user trys to change the url to navigate to the page, it is not displayed.
Page Edit
assigned by role on a per page basis.
users can add, move, or remove modules to any page for which they have this permission.
users can edit page settings, except for edit permissions on a page for which they have this permission.
users can edit settings and content for any module contained on a page for which they have this permission.
Create Child Pages
assigned by role on per page basis, works in conjuntion with Page Edit permission
users can create new pages beneath pages for which they have Edit and Create Child Page permission
child pages default to the same role permissions as the parent page but can be changed by Content Administrator
Module Edit
assigned by role.
users can edit the content of the module assuming they have at least View permission on the containing page.
users can edit Module Settings except for permission.
superceded by Page Edit permission, in other words if you have Page Edit permission you don't need module edit permission.
Module View
Module View permissions are supplemental to page view permissions. If the user is in the roles that are allowed to view the page then by default he is also able to view the module on the page. But if you specify only view permissions for roles the user is not in then the module will be hidden from the user when he views the page.
Envisioned Work Flow:
I will include 2 additional roles, Content Authors and Content Publishers to illustrate a possible workflow driven by roles. You might do something more elaborate with Department Authors and Department Publishers and delegate content management for different sections of a site to different departments, each with their own sub tree of the menu.
I will create a sample page named "Content Staging" and a series of child pages beneath it for authoring content. These pages will not be public as they will not have View permissions for "All Users". Content Authors will have edit permission on these pages and thus will be able to add and edit modules on these pages. Content authors might also be given Create Child Page permission on the main staging area page so they can can create pages for authoring content.
Content Publishers will have Page Edit permissions on all public pages in the sample data as well as the Content Staging pages. This will enable them to move modules from the Content Staging pages to the public pages.
The above scenario will allow formal enforcement of content approval by those in the Content Publisher roles. It serves only as an example, you could create additional roles and make it much more granular so that certain roles have publishing permission on certain pages and you could setup multiple staging pages so that each logical group can heve their own staging area and content approvers.
In a smaller shop you might choose a less formal approach and add all content writers to the Content Admins role and just verbally agree on when to move things from the staging area to the public pages.
You have multiple ways of publishing content. You can move a module from a page in the staging area to a public page, you can move a page from the staging area to be either a root page in the menu or a child page of another public page. You can change the View Permissions for the page to allow All Users or Authenticated Users.
You may also see other possible workflows that will suit your needs, I'm only trying to illustrate how the roles and permissions allow you to control content management. How you use it is up to you.
Update 6/7/2006 as of version 2.1, in addition to the above work flow we have a new Content Manager feature that allows users in the Admins Role and Content Administrators role to easily manage any published or un published content in the system. Any content instance can now be published on any number of pages instead of just one page as in the past. This new feature streamlines administration for those with full priveledges while the above scenario is still valuable for cases where you just want to allow someone to be able to edit a controlled area.