Roles:

Admins

cannot be deleted.
can do anything in the site regardless of other permission settings.
only role that can Add/Edit/Delete roles.
only role that can add users to roles.
only role that can create users independent of site registration.
only role that can configure site security settings.

Content Administrators

cannot be deleted.
can view any page in the site regardless of permissions except pages with Admins as the only role with View permissions.
can Add/Remove Pages.
can edit any page or module regardless of permission settings (except as above).
can determine what other roles can View/Edit a page.
can change site settings except security settings

Authenticated Users

cannot be deleted.
users are automatically added to this role but can be removed.
the purpose of this role is to make it easy to have pages where you have to be logged 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.


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.