The "User accounts" tab makes it possible to browse and manage nodes that belong to the "Users" top level node. This part of the tree is reserved for organizing user accounts and user groups. In addition, the interface gives access to the built-in permission system, making it possible to manage roles and policies. The following screenshot shows how the administration interface looks like when the "User accounts" tab has been selected.

Please note that in eZ Publish, user accounts and user groups are stored using nodes. In other words, when dealing with users and groups, the system works in the very same way as when dealing with other content like articles, folders, images, information pages, etc.

This part of the administration interface works in a similar way as the "Content structure" tab. It basically allows the user to organize and edit nodes. However, the "Create here" interface at the bottom will only allow the creation of classes that belong to the "Users" class group.

Access

Unlike the "Content" tree, the contents of the "Users" branch can not be accessed directly from the outside. The entire branch belongs to a section which the anonymous user does not have access to by default (please refer to the documentation page dealing with "Sections" in the technical manual for more information). Although the default behavior can be changed, it is highly recommended to keep this branch protected because it contains sensitive information.

Concepts

The built-in permission system is based on the following elements:

• Users
• User groups
• Policies
• Roles

The following illustration shows the relations between the elements in the list above.

Users, groups, policies and roles.

A user defines a valid user account on the system. A user group consists of users and other user groups. A policy is a rule that grants access to content or a certain system function. For example, a policy may grant read access to a collection of nodes. A role is a named collection of policies. A role can be assigned to users and user groups.

Usage

In particular, there are two things that the "User accounts" tab allows you to do. First of all, it allows you to manage your users and user groups using the node tree. Secondly, it allows you to manage your roles and policies plus have the roles assigned to different users and/or user groups. User and user group management works in the very same way as when you're dealing with articles, information pages and so on. Role and policy management is done using a .different interface

Managing user accounts and user groups

As pointed out earlier, users and groups are managed using nodes. This means that you can create, edit, delete, move, etc. your users and nodes in the same way as you would do when dealing with articles, folders, etc.

The built-in "User" class makes use of the "User account" datatype. This is a special datatype that plugs more deeply into the system. All objects that are using this datatype will automatically become valid users on the system. The "User account" datatype makes it possible to store a username/password combination and an E-mail address. The following screenshot shows the edit interface for this datatype.

Object attribute edit interface for the "User account" datatype.

Changing a user's password or E-mail address can be done by simply editing the user's node. Please note that it is not possible to change the username once it has been initially entered into the system.

Enabling and disabling users

By default, all user accounts are enabled. When disabled, an account will continue to exist, but the user will not be able to log in until the account is re-enabled. The enable/disable feature can be accessed by following the "Configure user account settings" link which is displayed in the preview window when a user is being viewed. The following screenshot shows the interface that will be displayed when the link is accessed. Please note that the "Number of concurrent logins" feature does not work and thus it is disabled for the entire system.

User account settings

It is recommended to use this feature whenever a user is to be removed from the system. The reason is because most likely, the user has relations to some nodes. For example, the user might have posted forum messages, written news articles and so on. Removing the user account will result in a state with broken relations. If the user has posted forum messages, it will not be possible to see that it was actually that user who wrote those messages.

Unlocking user accounts

From 3.9, a user account can also be automatically locked by the system if the number of failed login attempts is exceeded (this is controlled by the "MaxNumberOfFailedLogin" setting located in the "[UserSettings]" section of the "settings/site.ini" configuration file or its override). Once the account is locked, the user will not be allowed to log in until his account is unlocked by another user with administrator privileges.

User groups

User groups may contain user accounts and other user groups. In other words, a user group is just a collection similar to the concept of directories that contain files and subdirectories on a file system.

Additional windows

As in the "Content structure" and "Media" tabs, the horizontally aligned switches in the upper part of the main area control the visibility of the different windows. When the "User accounts" tab is selected, the system gives access to two additional windows called "Roles" and "Policies". When enabled, these windows will reveal detailed information about the roles and the policies that are valid for the user account or the user group that is being viewed. The following screenshot shows the "Roles" window.

Roles window.

In this case, only one role has been assigned to the user/group that is being viewed. The name of the role is "Documentation editor" and it has been assigned with no limitations. It is possible to directly edit the role by clicking on the edit icon(s). The following screenshot shows the "Policies" window.

Policies window.

In this case, the user or the group that is being viewed has access to two policies. Both policies are defined in the "Documentation editor" role. While the first one gives full access to the entire "Content" module (and thus all its functions), the second policy grants access to the "login" function of the "User" module.