Every user of the system generally should have a user account, though it is possible to create content in the KMS that may be viewed by anonymous users. Modifying any content requires logging in, which requires a user account. Every user account will have a password. The same username and password combinations are used by the web browser, Quick Upload, and Go-Between interfaces.

Every user will have some set of site-wide roles, with every user having at least the Member role site-wide. Users may also have any number of local roles. To be able to use the site, users will have to have some site-wide or local roles on some locations within the site.

The OpenEngagement DMS keeps a record of all significant actions, such as the creation of content, or the state changes of objects, performed by all users.

Unlike the Local Solution, there is no concept of Administrator or Manager roles, and so most of the setup and maintenance not directly related to the site's content is performed by OpenEngagement and not the site users. Firms will initially be given one user account, which will have a site-wide Site Manager role. OpenEngagement will give the username and password to the corresponding person, who may then change their password if they wish, and create as many additional user accounts as they wish.

Users, other than Administrators, may change their password in Preferences | Change Password.

The OpenEngagement DMS will have two initial users. The first has username admin and password admin. The second has username script and password script. This user account is used only to execute the scheduled overnight tasks.

Administrators have full power on an OpenEngagement DMS site; they may view, add, delete and modify any content, users, user groups and so on. One of the first tasks firms should perform with the OpenEngagement DMS is to create new users. These will have a variety of roles, but should include at least one Manager or Site Manager. Once these users are created, it is recommended users log on only as these users, and not as the Administrator unless necessary. With the Go-Between in particular, users should not use the Administrator role.

Generally, an OpenEngagement DMS instance will have only one Administrator, though it is possible to create additional Administrator user accounts. The Administrator user account is intended only for the rare administrative tasks done on the site and should not normally be used to access the site. The user using the Administrator account should then also create a Manager account with another username & password for themselves. They will possibly set this username to be their first or last name. They would, once this Manager account is created, usually log into the system using this user account. All other people using the OpenEngagement DMS would just have one username and password.

It is possible for a firm to create multiple installations of the DMS. If a firm installs multiple instances of the DMS, any user accounts created on one instance will not appear on the other instances unless the user accounts are specifically created there as well. This allows firms with multiple DMS instances to define different user access permissions on all sites.

Creating user accounts is a task performed when first setting up an OpenEngagement DMS instance, but may also be performed any time later, as is necessary. Creating user accounts requires logging on as an Administrator, Manager or Site Manager and going to the Site Setup page and then to the Users and Groups Administration page. The Site Setup page may be reached by users with sufficient permissions from most pages by clicking the link on the upper right portion of the screen, next to the Site Map, Contact and Log Out links. On the Preferences page, the Users and Groups Administration link is on the left side of the page.

To add a new user, click the button Add New User. This will bring up a form where you may enter their full name, username, email address, and possibly initial password. After submitting the form, you will be returned to the Users and Groups Administration page. Hit the Show All button to confirm the new user account has been created. They will initially have only one site-wide role, which is the Member role. All users must have this role site-wide (removing this role for any user may cause problems for the application). You may assign any additional site-wide roles you wish to give this user here, either now or later.

After a Manager or Site Manager creates users, if they specified the initial passwords for these user accounts, they can log on as these new users and double check they have access to what and only what they should. Once the Managers or Site Managers confirm the permissions are correct, they may then send the users their username & initial password. The users should then change their password.

As each user may receive email notifications from time to time from the OpenEngagement DMS, the email for each user should be specified. It is possible for the users to later fill this in themselves, but it is probably easier to fill this in when the users are created.

The Users and Groups Administration page also provides an interface where user groups may be created. These may be convenient for some firms, but are not necessary.

User groups are a convenient way to assign multiple people local roles. This is the main reason some firms may wish to create user groups. The OpenEngagement DMS ships with no predefined groups, but users may create as many groups as they wish. Most firms will not create any groups, but in some cases they may be convenient.

The OpenEngagement DMS allows assigning Groups local roles the same as individual users may be assigned local roles. Groups are simply a collection of users. For example, a site may include many users, including Alice, Bob and Carol. If an Engagement Manager wishes to assign Alice, Bob and Carol the Reviewer role for numerous engagements, the Engagement Manager may create a group consisting of those three users and assign that group the local role Reviewer. This is effectively the same as assigning Alice and Bob and Carol that role, but may be a bit quicker.

It takes some time to create groups, and if there are many combinations of users, such that many groups must be created, they may just create more confusion than benefit.  Where a site has the same combination of users given the same local roles for many objects, groups may be useful, though.

Groups may also be useful where a firm wishes to assign a group to local role, say Entity Manager for many Entities, then later dynamically change the membership for this group. For example, a Manager can create a Group called Senior-Partners, which consists Alice, Bob and Carol. The Manager may then assign this group the Entity Manager role for, say, 300 Entities. After firing these people and replacing them with Alison, Brad and Cynthia, the Manager may simply change the membership of the Senior-Partners group, and these three users will now have the Entity Manager role for the 300 Clients.

It is not possible to have hierarchies of groups. That is, you cannot define groups of groups of users. This should not present any real limitation to OpenEngagement DMS users.

There may be some confusion between the concepts of users being in user groups and users having roles. One key difference is users can have different roles in different locations of the site, but their membership in the user groups is site-wide. The user groups may, though, have different roles in different locations of the site. 

Passwords for new user accounts may be either random passwords generated automatically by the OpenEngagement CMS or may be specified by the user who created the user account. In the latter case, users should change their password to something only they know, which can be done by going to the Preferences page, and clicking the Change Password link.

To specify that the OpenEngagement CMS should generate passwords automatically, users can go to Site Setup, Portal Settings. If this is selected, the user's password will be sent to them. This password will be very secure, and users should be encouraged to use it if they can reliably remember it. Otherwise, they should change it.

The OpenEngagement DMS also has a Forgot Your Password tool, where users may enter their username and their password will be emailed to them. Users should check this works properly when first logging into the DMS.

It is also possible for Managers and Site Managers to reset the passwords of any user. This is done in the Users and Groups Administration page.

Passwords are used by the DMS, KMS, Go-Between and Quick Upload.

Passwords for Administrator user accounts (available with Local Solutions) can be changed in: http://<servername>:8080/acl_users/manage_main. From there, click on the users link and then the name of the user account for which you wish to change the password.

It is very important that all users specify secure passwords. This means passwords that others can not guess and can not derive by running a script that executes a dictionary attack. A dictionary attack is where a script tries, one at a time, hundreds of thousands of passwords for a given user account. Doing this, if the password is weak, such as 'abc' or a word in the dictionary (hence the name of the attack), a person can often within one or two weeks determine a user's passwords. If strong passwords are used, which are at least 6 characters long and contain both letters and numbers, these sort of attacks generally take years to execute and are therefore not practical.