CaseWare Working Papers also has the concept of roles. However, the Working Papers roles apply only within an engagement. The two security systems compliment each other and do not overlap.

Working Papers does not come with any set of default roles; it simply comes with a set of permissions. Users create the roles themselves and may create as many roles as they wish, associating a set of permissions with each role.

The permissions within a Working Papers client file are not equivalent to those in the OpenEngagement DMS, which means the OpenEngagement DMS cannot assume any DMS-level permissions should be applied based on the roles within the client file; the OpenEngagement DMS is not able to extract any of the permissions defined in Working Papers and apply them in the DMS. Permissions in Working Papers have to do with access to specific portions of an engagement, which does not apply to the DMS. As well, there’s nothing in Working Papers that would define the OpenEngagement DMS permissions.

The roles often created by Working Papers users and used within Working Papers may be similar to those within the DMS. For example, both systems may have Reviewers. However, the Reviewers within the client files will perform client file-level reviews, while the Reviewers in the DMS will perform DMS-level reviews, which may be quite different types of review.

Users can perform actions only if any of their site-wide or local roles give them permission to. The roles are additive, so users usually have more roles as they navigate down the tree. For example if the site is organized as such:

Root
    DMS Area (Area) (Alice - Reader)    
        Client XYZ (Entity) (Alice - Preparer)    
            Tax (Section) (Alice - Engagement Manager)    
                tax2004 (Engagement) (Alice - Manager)

Here, the object types are shown in parenthesis and the local roles in red. The user Alice has the Reader role at the Area level. She has the Reader and Preparer roles at the Entity level. She has the Reader, Preparer, and Engagement Manager roles at the Section level, and she has all four roles at the Engagement level.

The OpenEngagement DMS has several roles, ordered roughly from most to least power:

-Administrator
-Manager
-Site Manager
-Entity Manager
-Engagement Manager
-Reviewer
-Preparer
-Reader
-Member
-Anonymous

Roles give users permissions to perform certain actions. For example, one permission is the permission to view an Engagement. Users with the Reader role may view an Engagement, but users with only the Member role may not.

When a user first views the OpenEngagement DMS using a web browser, they are not yet logged in. (This is not the case when using the Go-Between, since with the Go-Between, giving your username and password is done before anything else). They are, then, Anonymous. Once logged in, they will have at least the Member role site-wide. The Member role, however, grants the user very few permissions. They may, though, also have additional roles, either across the entire site, or within specific parts of the site.

Once logged in, it's often possible for a user to close their web browser and then open another browser shortly afterward and have their session preserved. In this case, they won't have to log in again. If users explicitly log out, or leave their web browsers closed for too long, they will have to log in again the next time they access the site.

Users may often have multiple roles. For example, they may, site-wide, have both the Entity Manager and Engagement Manger roles. This means, anywhere on the site, they may perform any actions that are permitted by either the Entity Manager role or the Engagement Manager role. Note though, it is recommended that most users do not have any site-wide roles, and that for the most part, users are given only local roles.

Giving a user site-wide roles is equivalent to giving them those roles at the root.

The Engagement Manger, Preparer, Reviewer and Reader roles apply specifically to permissions related to Documents, and the Entity Manager role applies specifically to permissions related to Entities. The Site Manager role is equivalent to having the Entity Manager and Engagement Manager roles, as well as some additional permissions (deleting content, creating and deleting users, access to the Keyword Manager tool and so on). Managers have all the power of Site Managers, and as well have access to most of the ZMI. Administrators have all the power of Managers, and as well have access to all of the ZMI.

Note though, the Manager and Administrator roles are available only on Local Solutions, where access the ZMI (a set of administrative pages) is necessary. As the Manager role only pertains to granting access to the ZMI, the Manager role can only be assigned site-wide and not locally.

Different firms have different staff hierarchies, but the assigning of roles in the DMS will likely be based at least partially on the users' positions within the firm. One example of mapping the positions within a firm to the roles of the CW CMS is:

Partner   – Manager, Site Manager
Supervisor  – Engagement Manager, Entity Manager
Senior Staff – Reviewer, Reader
Junior Staff -- Preparer, Reader

In many firms, particularly smaller firms, the Engagement Managers would also be the Reviewers, and we would not need two separate roles for these. Larger firms, with possibly large engagements, will more often utilize all these roles. Though even within large firms, with small, non-critical engagements, DMS-level reviews may not be necessary; it may be sufficient to simply perform the Working Papers-level reviews, and in this case as well, firms may not assign Reviewers to certain Engagements.

As well, with small firms, there may often be only a single person responsible for an Engagement. In this case, instead of assigning this user the Engagement Manager, Preparer and Reviewer roles, the firm would likely assign this person only the Engagement Manager role. The presence in the DMS system of multiple roles is a useful feature, and is often necessary, but where it is not necessary there is no need to utilize all the various roles.

The Administrator user accounts are created only with Local Solutions. The role does not appear on Hosted Solutions. The tasks which may be performed only by Administrators will be performed by OpenEngagement for Hosted Solutions, and should need to be performed very rarely if ever by Administrators of Local Solutions.

Administrators have full access to the ZMI (Access to the ZMI is described in detail in this documentation). The ZMI is available only to Administrators and Managers. Managers have access to the bulk of the ZMI, but not all of the ZMI. The portion of the ZMI available to Administrators but not Managers is fairly small and contains only a couple features which may be of use to OpenEngagement DMS users. One is the ability to create additional Administrators, which is done under acl_users. It is not possible to assign users the Administrator role any other way, and it is not possible to assign users local Administrator roles.

The other tasks which only Administrators may perform are restarting the server and database packs, which are described in this documentation.

Administrators have no associated email accounts, so some functionality of the site will not work properly when users are logged in as Administrators.

It is recommended that users do not log into the CW CMS as an administrator unless necessary. For the most part, this documentation will not mention Administrators, as they should not perform actions on Entities or Documents and are not relevant to the workflow.

For many firms, the Administrator account will be used only once, after first installing the DMS, in order to create the other initial user accounts and to change the administrator password. If Administrators do need to access the full ZMI, where the URL for the main site is, say, http://siteaddress/CMS, the URL for the ZMI will be http://siteadress/manage.

The Manager role appears only with Local Solutions. The Manager role is equivalent to the Administrator role, with the exception that Managers do not have access to all of the ZMI. As well, the Manager role is equivalent to the Site Manager role, with the exception that Site Managers have no access to the ZMI. With Hosted Solutions, as with the Administrator role, any tasks that may be performed by Managers will be performed by OpenEngagement.

It is not necessary to assign any users the Manager role with Local Solutions. Firms may choose to have Administrators perform all actions in the ZMI and to give all other users at most only the Site Manager role. As access to the ZMI should be quite rare, this may be reasonable. However, users should try to avoid using the DMS as Administrators. If access to the ZMI is common, likely the firm should assign one or more users the Manager role site-wide.

The Manager role may be assigned only site-wide.

Within the ZMI, Managers may make site-wide changes, such as changing colours and fonts, adding and modifying roles, and modifying the workflow. Most of these changes are difficult and risky, so it is not advised for users to do this on their live instance of the OpenEngagement DMS. They may, however, make these changes on other instances of the DMS firms may install for the purpose of experimentation and development.

Other than access to the ZMI, Site Managers have all the power of Managers. Site Managers have the full power of both Entity Managers and Engagement Managers. As well, there are two key additional permissions Site Managers have beyond those of Entity Managers and Engagement Managers. The first is, Site Managers and Managers are the only roles which may delete content. The second is, Site Managers and Managers are the only roles that have full access to the Site Setup page. Access to the Site Setup is given only to users who have the Site Manager role site-wide, not to those who have it only locally. The Site Setup page includes tools such as the Keyword Manager, Mail Settings, Navigation Settings, Portal Settings, Search Settings, Users and Groups Administration, and the OpenEngagement Configuration. Each of these is described in this documentation.

Entity Managers may perform any action related to Entities, other than deleting, but the role gives them no permissions to act on Areas or Documents, other than viewing. Entity Managers may edit Entities, change the state of  Entities, and create Sections within the Entities. One of their main tasks, though, is to assign the Engagement Managers for the Entities. In some firms the Entity Manager role may not be used, and these tasks may be performed by Site Managers or Managers.

Entity Managers also have control over Sections where the Sections appear within an Entity. Entity Managers have no permissions on Sections that appear directly within Areas.

Engagement Managers are named as such since they will likely do the most work and the most important work on Engagements. The role, though, applies equally to all Document types: Engagement, Page, File, Link and Image.

Engagement Managers may perform any action on Documents other than reviewing or deleting. Engagement Managers may, among other things, sign-out, edit, upload files, assign local roles, modify the keywords, and change the state of Documents.

If a Document has a set of one or more Reviewers assigned to it, then only these Reviewers may mark the Document as approved, and the Document can not transition to the Reviewed state until each of these Reviewers has approved the Document. If firms wish for the Engagement Manager, or some of the Engagement Managers if there are more than one,  to review the Document as well, then these users should also be assigned the Reviewer role.

Engagement Managers may transition the Document to the Completed state without the Reviewers completing their review. In this case, the history for the document will indicate this transition and will show that the reviews were not completed.

Preparers have the rights to view and edit Documents while they are in the Active and Review states. After these states, Preparers have no permissions on the Documents. If firms wish for users to have permission to view Documents after these states, they should additionally assign these users the Reader role.

Preparers may sign-in/sign-out Documents, edit the fields, upload & download files within an Engagement, File or Image, and mark the Documents as ready for review (that is, move them to the Review state). They may not create or delete Engagements, modify the keywords or assign local roles.

As with all other roles, there may be multiple users assigned the Preparer role to a Document. During the Active state, there may, then, be several users signing-out the Document, one at a time. While they are signed out by other users, Preparers may only view the Document. Once in the Review state, there may be several Preparers and several Reviewers editing the Document, again with at most any one user having it signed out at a time. This ensures no two users attempt to edit the Document at the same time, thereby wiping out each other's work.

Preparers can sign in documents whenever they have them signed out. For example, a Preparer may sign-out a Document while it is in the Active state. A Reviewer may then move the Document to the Reviewed state. Though the Preparer cannot sign out the Document now that it is in the Reviewed state, they may still sign it in.

Reviewers may view and edit Documents while in the Review state. As with all other roles, users must first sign-out Documents before they may edit them. To perform a DMS-level review, Reviewers may not need to edit the Documents. Working Papers provides a review list within the Client Files. Reviewers may wish to use this as part of their DMS-level reviews. However, they may not use the review list or otherwise edit the Documents. In this case there is no need to sign-out the Documents. As another example, Reviewers of Page objects may not wish to actually edit the Page; they may simply read it and mark it as approved.

The OpenEngagement DMS allows for Reviewers to review portions of a Document, such as individual sections within a Working Papers client file, or certain sections with a large Page object, and so Preparers may continue working during the Review state. While Reviewers are performing reviews, they may wish to either sign them out, or mark them as read-only, in order to ensure other users do not modify them during the review.

In order for a Document to transition from Review to Reviewed, each Reviewer, site-wide and local, must approve the Document. If is possible in the page for a Document to see which reviewers have and have not completed their review for the Document.

Generally, firms should not assign the Reviewer role site-wide, since this will require any users assigned as such to review every Document in the DMS. With small firms, though, this may be acceptable.

The Reader role is given to users who must view, but not edit, Documents. This may be assigned for a variety of reasons, including allowing users who are given the Preparer, Reviewer, or Engagement Manager role for one Engagement to view the Engagements for prior years for the same Entity.

The Reader role gives users permission to view Documents regardless of their state.

Readers may download files enclosed in Engagement and File objects. In the case of Working Papers client files in Engagements, Readers may download only read-only copies of the client file.

All users are given the Member role site-wide. The Member role allows users to view Areas, Entities and Sections. However, the tables in the Documents tabs for these objects will list only the Documents the current user has permission to at least view.

With most firms, most users will be given only the Member role site-wide, and will be given additional roles locally. With the exception of Documents, Members can see all objects in the Navigation and by searching. This ensures that all Members, regardless of how few local roles they may have, are always able to navigate to the Entities or Documents where they have some local role and some work to perform.

Anonymous users may do virtually nothing other than view the front page and log into the OpenEngagement DMS. There may or may not be content in the KMS, however, that they can view. This ensures users without a valid account will not be able to view or edit any content not specifically set Public. Anonymous users are not able to view or edit any content within the DMS.

Assigning local roles may be done by Managers, Site Managers, Entity Managers and Engagement Managers. Users may assign local roles to themselves or other users. For example, an Entity Manager may assign themselves as an Engagement Manager for a certain Section. In most firms, acting as an Entity Manager will not be any user's sole responsibility; they will also have other roles and may at times assign themselves. As another example, Engagement Managers may assign themselves as Reviewers.

Users can not assign themselves or other users a more powerful role than they themselves possess. For example, an Engagement Manager can not assign another user the Site Manager role.

Site Managers may assign any user (including themselves) any role other than Manager to any object

Entity Managers may assign any user (including themselves) the Entity Manager or Engagement Manager role to any object, but are not be able to assign Preparer, Reader, Reviewer, Site Manager or Manger roles.

Engagement Managers are able to assign any user (including themselves) the Engagement Manager, Preparer, Reviewer and Reader roles to any object. They are not able to assign Site Manager or Manager roles.

Preparers, Readers and Reviewers cannot assign any local roles.

The Local Roles tab is used to assign users local roles and to view the local roles currently given to and inherited by users. This tab does not list the site-wide roles, however. To add a local role, users navigate to the relevant object and to its Local Roles tab. At the bottom of the Local Roles Tab, select the user's name from the combo box, select the appropriate roles, and hit the assign local role to selected user(s) button. You will then see this user with their new local roles appear above, in the Assigned Roles section of the page.

Users must sign out the object before they can set the local roles, in order to avoid two or more users modifying the local roles at the same time.