User account types
Learn about the different user accounts available in Matrix and how to add, edit, and activate these user accounts.
- User account types
- User screens
- Activating a user account
- Updating user passwords
- Incorrect password attempts
- Morphing account types
- Sign in as another user
There are six different user accounts available in Matrix:
There is only one root user account within a Matrix system. It is stored under the System administrators folder within the asset tree.section of the
The root user has the highest access within the system and can view and modify all fields and screens within Matrix.
The root user cannot have any of their permissions removed. Matrix will ignore any attempt to remove root permissions. The user will retain the ability to view and edit any asset.
The root user is located under the Root users group and cannot exist outside of this group. You can give other system administrators root access by moving/linking them into the Root users group. Only a user with root-level access can only do. User groups or LDAP users cannot be under the Root users group.
It is good practice to move at least one system administrator into the Root users group and then disable the root user account altogether. For more information on how to disable the root user, refer to the Annotated main.inc documentation on Matrix Manuals.
A system administrator can view and modify most fields and screens within Matrix. They are automatically given admin permission to all assets in a Matrix website. Still, they cannot edit all fields and screens within system configuration and system management.
The main difference between a system administrator and a Backend user is that you can link a system administrator within the root users group. Doing so promotes the account type to a root user account.
System administrator accounts must be in the System administrators folder within the System management section of the asset tree. If these accounts are not in this folder, Matrix will not consider user accounts as system administrator accounts.
System administrator accounts can create new user account types up to and including other system administrator accounts. This account type can also upgrade user account types lower than their own through the Morphing account types feature.
You can create as many system administrators as you want within your system. You can also link a user group under the System administrators folder to assign all users within the group as system administrators.
A backend user can sign in to both the inline edit and administration interfaces. They will not be able to edit assets within the site until they have the required permissions. A backend user needs read permission to view an asset and write permission to edit an asset.
|A Matrix user needs at least a backend user account to be able to edit a site.|
The main difference between a backend user and a Content editor is that a backend user can create all asset types by default. You can also link this account type within the system administrator group. Doing so promotes the account type to a system administrator account.
A backend user can also be given admin permission to an asset. This permission grants administrator-level access to the selected asset but does not grant full system administrator account permissions. Read the Permissions documentation for detailed information about permissions.
You can create as many backend users accounts as you want within your system. If backend users have "write" permissions to the Backend user folder, they can create other backend user accounts.
By default, only a system administrator or the root user can create a backend user. Backend user accounts should be in a user group under the Users folder. Read User groups for detailed information about user groups.
A content editor has limited access to certain backend UI features, such as specific tools and asset screens. This user account type can only create a limited set of asset types.
Like a backend user, a content editor will not be able to edit assets within the site until they have the required permissions.
A content editor needs "read" permissions to view an asset and at least "write" permission to edit an asset.
A user account is for a public user who has a member status within your site.
For example, if you have a member’s section on your site, a person needs a user account to access it. A user account does not have access to either the inline edit or administration interface within Matrix.
Only backend users, system administrators, or the root user can create a user account. The account should be in a user group under the Users folder. To view an asset, you need to grant a user read permission to the asset. You can create as many user accounts as you want within your system.
You can create an account manager page to allow a public user to create their user account and maintain their account details. For more information on the Account manager page, read the Other CMS assets documentation on Matrix Manuals
A public user is created within Matrix and is stored, by default, under the Users folder in the asset tree.
A public user has no access to either the inline edit or administration interface within Matrix. They can only view the content on your live site. You need to grant the public user read permission to the asset for them to view an asset.
The details screen lets you configure the user and password details for a user account. You can also view the current locks a user has and choose to release them if you have Admin access over their account.
The username of the user account. Use this name to sign in to the Matrix system.
The password used to sign in.
These fields are blank and only used if you are changing the user’s password. Password creation rules display below the field.
These fields are disabled if an external authentication system using OAuth or SAML created the user with the Disallow password sign-in option enabled.
- First name
The user’s first name.
- Last name
The user’s last name or surname.
The email address of the user. Matrix uses this email to send any system messages to the user. These messages include workflow notifications and password reset instruction emails.
This email address will also receive any messages sent to this user’s Matrix inbox.
You can use this value when accessing the user’s email address using keywords (such as
%asset_attribute_username%) and other functionality that sends emails to Matrix users.
This section lets you view and release the locks that the user currently holds. The Show user held lock details button will display the last 100 locks that the user has held.
To release the locks held by a user, selectand click Save. If you have not acquired the lock on the details screen, a button is seen instead of a list in the Release held locks field. You can release the locks by clicking the Release all locks button without first acquiring the locks.
|If you release all locks while a user is working on an asset, they will lose uncommitted changes.|
The Restrictions screen on a user account lets you add a condition to restrict the user’s inclusion in User Groups.
Each blue heading represents a user group that currently includes the user account. For example, in the previous figure, this user is part of the Content authors user group.
You can create a different set of conditions for each user group on this screen.
If this user is not part of a user group, you cannot use the Restrictions screen.
To add a condition, select which type you want to use from the Add new condition list and click Save. Additional fields will then appear on the screen, allowing you to configure that condition. You can add as many conditions as you like.
This manual does not discuss the following conditions as you should only use them under very particular circumstances:
Admin access condition
Form posted condition
Keyword regexp condition
User type condition
Write access condition
The other available conditions are:
- In user group condition
Specifies that the user account is only a user group member if they belong to another user group.
- Signed-in condition
Specifies that the user account is only a user group member if the user is signed-in.
- Server variable condition
Specifies that the user account is only a user group member if a specific user variable matches the pattern specified.
An example of this condition would be that you can specify that the user is only part of the user group if the browser they are using is Internet Explorer.
To do this, select The following server variable matches the specified pattern from the list provided, enter
HTTP_USER_AGENTinto the Server variable field, and enter
MSIEinto the Pattern field.
- Inline edit mode condition
Specifies that the user account is only a member of the user group if they use the Simple Edit Interface.
- User agent condition
Specifies that the user account is only a user group member if they are using a specific browser.
An example of this condition would be that you could specify that the user is only part of the user group if the browser they are using is Internet Explorer. To do this, check the browser user agent string matches the pattern from the list provided and enter
MSIEinto the User agent pattern field.
- User frequency condition
Specifies that the user account is only a user group member based on the amount of time on the site or the number of visits to the site.
- User IPv6 condition
This condition works in the same manner as User IP condition, using a specified IPv6 range.
- User IP condition
Specifies that the user account is only a user group member if they have a particular IPv4 range.
To add a new IP address:
Enter the Network IP Address and Subnet Mask into the fields provided.
Selector and click Save.
You can add as many IP addresses as you want to the list. You can also choose to grant or deny access to the user account if the IP address is outside one of the IP ranges specified in the list.
If you have a long list of IP addresses you need to add, you can create a CSV file and import it. The format of the CSV file must be a file without a header row. Each line in the file contains six fields:
The first four fields should be the octets of the Network IP Address. For example,
The fifth field is the Subnet Mask in CIDR format. For example,
The sixth field is either one (
1) for Grant or (
0) for Deny.
When you create a user account, its initial status is Under construction, which means that this user account is inactive and can not sign in to Matrix.
For a user account to be active, the user account’s status needs to be Live.
|You can create a trigger to automatically set a user account’s status to Live once created. Read Working with triggers for more information about setting up triggers to manage account statuses.|
If you set the status of the user account to Up for review, Matrix will force the user to change their password next time they sign in to the system.
|You can create an automated trigger to set an account’s status to Up for review after a specified period of being live. For more information on how to do this, refer to the Triggers manual.|
When the user logs into either the inline edit or admin interfaces, the Change password pop-up appears:
To change their password, the user must enter their current password into the Current password field and their new password into the New Password field. They must re-enter their new password in the Confirm new password field. Once they have entered their new password, they click the Update Password button.
If any password rules apply, they will appear above the password entry fields. For example, in the figure shown above, the rule Password must be at least six characters long appears on the screen.
The status of the user account will then change to Live.
By default, if users incorrectly enter their password three times, their account becomes inactive. The status changes to Under construction. For the user to sign in again, you need to change their account status back to Live.
This option can be disabled, or the number of attempts changed within the System configuration section of Matrix.
For more information, refer to the System configuration manual.
Morphing lets you change a user’s account type. For example, as a system administrator, you could change an account type from User to Backend user.
To morph a user account:
Navigate to the Settings screen of the user account.
Scroll down to the Morphing section.
Select which account you want to morph to in the Type list
There are some basic rules and restrictions that apply when you morph user accounts:
You cannot morph the system’s root user and public user assets.
You are only able to morph a user account to a type you can create.
You can only morph user accounts to which you have admin access.
A backend user can not morph a content author account into a backend user account type.
A system administrator can not morph a backend user to a system administrator account.
The Sign in as tool allows a system administrator or root user to switch to another user account for troubleshooting purposes.
This tool may allow you to reproduce a problem that has been reported by a specific user.
To sign in as a different user, click.
Enter the user’s user name that you want to sign in as and click Sign in.
The Sign out icon in the toolbar also changes to indicate that you are signed-in as another user.
To revert to your user account, click the Sign out icon. You can also right-click on a User asset in the asset tree and choose the Sign in as option to do the same thing.