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.
Endpoints
http://deepserhost/api/rest/user/[id]http://deepserhost/api/rest/user/[id]Roles
Here we list all the permissions by user role regarding the API:
| Admininistrator | Agent | Key User | User | |
|---|---|---|---|---|
| Actions Allowed | RETRIEVE CREATE UPDATE DELETE | RETRIEVE | RETRIEVE |
Fields
Here we list all the fields of the entity to describe their meainings in Deepser:
| Field | Meaning |
|---|---|
| user_id | The unique ID to identify the record. |
| avatar | Icon with the user avatar. If not set, it will be chosen randomly from the system. |
| username | Username 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. |
| role | The role of the user. Please refer to the Roles in your system to get the correct IDs. |
| firstname | First name of the user |
| lastname | Last name of the user |
| Email 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. | |
| password | Password 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_active | It 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_page | Page to which the user is redirected after the login. This field contains a list of all the system pages. |
| locale | Language of the user. Deepser has a native support to many languages. It is possibile to translate the software using this short guide: Translate Deepser |
| timezone | Timezone 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_id | Company 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_supervisor | If 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_visibility | A 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_id | The form template ID used by the record. Please refer to the Formtemplate ID guide of Deepser Docs. |
| modified | Last update date of the record. |
| created | The creation date of the record. |
| display_username | The username displayed in the system (typically Firstname + Lastname). |
