User types are used to assign user permission to perform the available functions in the system. User types are objects that contain a set of abilities grouped by the system's functions, for which a permission is assigned from the following available levels:
- not_allowed - The user is not allowed to perform this ability.
- self - The user is allowed to perform this ability for resources belonging to their company only.
- self_and_all_children - The user is allowed to perform this ability for resources belonging to their company or any sub-account of their company.
As an example, each user type has an ability object governing the "rules" feature of the system. Rules can be created, read, updated, and deleted. Consider the following fragment of a user type and its rules ability.
{
...
"abilities":{
"rule": {
"create": "not_allowed",
"read": "self_and_all_children",
"update": "not_allowed",
"delete": "not_allowed"
},
...
}
This would define a user type that had read-only access to rules.
Permissions Apply to Hierarchical Accounts
To understand the difference between self and self_and_all_children, it's important to understand that the system's account management is hierarchical. In other words, it's possible to restrict a user type's abilities by permission level as well as restrict a user's ability to affect a sub-account. Consider this updated rule abilities definition.
{
...
"abilities":{
"rule": {
"create": "not_allowed",
"read": "self",
"update": "not_allowed",
"delete": "not_allowed"
},
...
}
In this case, because of the self permission value for read, the user with this user type would only be able to ready rules for their company, not any of the company's sub accounts.
For more information about companies and sub-accounts, see the Account Administration and the Companies API documentation.