User API

The User entity is used to manage users that can login to Deepser.
Users can be only created by Administrators that can access the User Module.
Agents and Key Users can only retrieve the Users.
End Users cannot access this resource via API.




Here we list all the permissions by user role regarding the API:

 AdmininistratorAgentKey UserUser
Actions AllowedRETRIEVE


Here we list all the fields of the entity to describe their meainings in Deepser:

user_idThe unique ID to identify the record.
avatarIcon with the user avatar. If not set, it will be chosen randomly from the system.
usernameUsername used by a user to access the software. It is the field that uniquely identifies the user.
Username is thus used for the login to Deepser. If we create manually a user, we can choose the username we want.
Obviously, user name must be unique otherwise the system will block the creation of a user with a username already in use.
If we insert users with the LDAP integration the username will be the LDAP attribute we chose when configuring the integration, but Deepser prepend a number and a backslash (\) to identify the ID of the LDAP directory from which we are importing the user.
In case of LDAP users, the login screen of Deepser will change, adding a select-box to choose the domain. This select-box is thus mandatory for the users with an LDAP account.
A user manually inserted has, for example, this username: admin or name.surname, or rather the email of the user.
A user imported from LDAP will have, for example, this username: 1\name or 1\name.surname.
Looking at the ID of the LDAP directory we can easily find from which LDAP source the user has been imported.
roleThe role of the user. Please refer to the Roles in your system to get the correct IDs.
firstnameFirst name of the user
lastnameLast name of the user
emailEmail of the user to receive notifications. Email is a very important field if we activate the email integration: Deepser send all the emails to users according to this value.
passwordPassword to log into the system. Password is encrypted in the database. If a user is an LDAP user the password will not be saved in the database, but the system will try to authenticate directly to the LDAP server.
is_activeIt tells if an user is active in the system. Non-active users are not displayed in the select-boxes of Deepser modules, cannot receive emails and cannot log into the system.
startup_pagePage to which the user is redirected after the login. This field contains a list of all the system pages.
localeLanguage of the user. Deepser has a native support to many languages. It is possibile to translate the software using this short guide: Translate Deepser
timezoneTimezone of the user. Timezone is applied when displaying the dates on the interface. Infact, in the Deepser DataBase all dates are stored referring to the system timezone: UTC. This setting allows the system to manage all the dates with consistency and not to have problem with the variaton of dates based on the location of a user.
company_idCompany of the user. All users can be part of one (and only one) company. Companies are explained in that guide: Company Guide.
Companies can be grouped in a 2 level structure: one company is the Parent and can have multiple sub-companies. That way we can manage the visibility of the requests allowing, for example, a corporate manager to see all the sub-company requests and allowing a director of a sub-company to see only data of his smaller organization.
is_supervisorIf the user is a supervisor he can see data of all users of the company (and sub-companies). This field is very important to determine which data cha see a user within his organization. If the user is a supervisor and can access the back-end (Administrator, Agent, Key-User) he can see all data of his Company and sub-companies. This is true if the user has the field Company Visibility set to Limit Data to Company. On the contrary, the user can see all data in the system.
If we talk about a user with type “User” (an end user/customer), this user can only see the data regarding his requests (and no other). But, if the user is configured as supervisor can see all the Service Operations of his Company (and sub-companies if present).
company_visibilityA user with this field set can see only data of his company (and sub-companies). If a user access the back-end this field is very useful to limit the visibility. Think, for example, to an operator that can only manage requests from his brach. If we create a company specifically for the branch and limit the data of the user to that branch, the operator will not see any other company data.
Talking about a user of type “User” this field is always ignored, because the user can only see his records and if the field Is Supervisor is set to true, then he can also see the data of his company.
formtemplate_idThe form template ID used by the record. Please refer to the Formtemplate ID guide of Deepser Docs.
modifiedLast update date of the record.
createdThe creation date of the record.
display_usernameThe username displayed in the system (typically Firstname + Lastname).