This Course will give you a better knowledge on how Rights, Permissions and General Visibility Works in every Deepser’s Module. We will talk about Users, Groups, Roles and Companies from the System Admin Perspective.
In Deepser the resources are basically the modules or service that Deepser makes available.
An example of the exposed resources is shown below.
The visibility of the resources in Deepser can be set up to the model level.
The user will only be able to see modules and resources that have been set as visible to the membership role.
In Deepser, roles are used to define which resources the user will have access to.
We can exemplify the concept roles manage Vertical visibility in Deepser, that is, the visibility of the modules presents in the sidebar
The default roles in Deepser are:
| Role | Description |
| Admininstrator | Administrators Users in Deepser, are users that have global access and bypass the limits of visibility in the backend, in addition to them have faculty to modify the grids and form templates. This is the only role that has access to the system configurations and the System tab. |
| Super Admin | Super Admins are users with Administrator role who have set “All” in the resource visibility section. This role is the only one that has access to scripting areas. |
| Agents | These Users have the right to modify the grids and form templates, but they do not have access to the scripting areas or even to the modules placed in the System tab. For the rest by default, they have global access to all other modules. |
| Key Users | These users are comparable to Agents users, but unlike the latter they have no ability to modify any system configuration, including grids and form templates. |
| Users | These are the end users, as a rule, these users do not have access to the backend but only to the end user portal. Since they do not have access to the backend, they cannot change any system configuration or even see the tickets that have not been opened by them. If there is a need for an end user to see tickets not opened by himself, he can be modified by setting him as a Company Supervisor, in this case the user will be able to see all the tickets created by his company. Alternatively, you can configure the user as empowered user, this will give him visibility even on tickets not belonging to his company. |
In deepser, roles are an important component in visibility management.
The roles allow you to manage the visibility of the modules accessible to user accounts (e.g. password, crm etc) or even which users can access the Deepser backend and which can only access the user portal.
To create a role in Deepser you will have to go to the “System the Permissions->Roles” menu.
At this point in the screen that will open you will have to click on the “Add New Role”
On the next screen you can set the “Role Name” field which will define the name that will have the new role.
In the type field it will be possible to define the Type that will have this role by compiling the “Type” field.
Then moving to the “Roles Resources” tab you can define which resources will be visible to the user to whom this role will be assigned by configuring the “Resource Access” field to Custom an selecting the resources you want to expose to this role.
Note: if you want to set the role to have no visibility limitations you can opt to select from the drop-down menu the item “ALL” instead of the item “Custom”, in this way no visibility limitations will be applied on the role (however this will not affect the visibility configured for groups).
Now click on the “Apply” or on the “Save” button.
Once the role has been created, a third item will appear in the list of tabs: Role Users.
Using this tab you can get a quick overview of all the users who have been assigned that role.
A user in Deepser is an individual who interacts with the system, utilizing its features and functionalities.
To create a new user in Deepser you will need to go to the menu System -> Permissions -> Users(1)
In the screen that will open, you will need to click on the “Add User” button(2)
At this point, the following screen will open:
| Field | Description |
| Avatar | Profile picture of the user. |
| Username | Username of the user, this will serve to log in, this is a mandatory field to create and in addition this field must be unique within Deepser. |
| Firstname | The name of the user. This is a required field |
| Lastname | User’s lastname. |
| User’s email | |
| Password | Password of the user, note that this field is always white because the user’s password is not stored in a database format that is invertible, consequently the field remains unvalued by default even if the user has a password set, except when changing the password itself. In case of changes to this field when saving the user Deepser will automatically update the value of the password present in db. |
| Password Confirmation | Confirm the user’s password, like the previous field, this is also not valued except when changing the password itself. |
| Role | The role of the user, depending on the role the user will have different visibilities on the various parts of the product. For example the Users role, who by default sees only the End User Portal. The roles of the users will be deepened in the dedicated Lesson, click here to go to the corresponding lesson. |
| Active | Indicates whether the user is authorized to access Deepser. If the value is “Active” the user will be enabled to access, if the value is “Inactive” then the user will not be authorized to access Deepser. |
| Startup Page | This field indicates which is the default page to which the user will be redirected after logging in. |
| Local | Indicates the language in which the user visualizes Deepser interface |
| Timezone | It indicates the time zone associated with that user, it is important to indicate the correct time zone so that Deepser can correctly set the format of the dates in notifications and date fields. |
| Company | The company field indicates which company the user belongs to, this field is very important since Deepser companies are one of the key elements in visibility management. The companies will be analyzed in the following lessons, click here to go to the lesson on the companies. |
| Additional Companies | Additional companies indicate to the data of which other companies the user will have access. This topic will be deepened in the lesson on company, this field will be selectable only after the user has been saved at least once |
| Is Supervisor | This field indicates whether the user will be a company supervisor. A company supervisor will have the ability to view and modify the tickets created by the users of his company |
| Company Visibility | This field indicates if the user will have limited visibility to Company Data |
| Portal CMDB Visibility | This field indicates if the user will see the cmdb in the user portal. |
| OTL Token | This token if passed as a parameter (token) in the url of the request (query string) allows you to access Deepser without logging in. Note that the setting of direct access by token is by default disabled for security reasons, in addition for security reasons this token has validity of only one use, after which it is automatically reset by the system, this is done to avoid data theft. |
| rp_token | This token is used to reset a user’s login credentials. This is a system field, at the operational level there is no use for this field. |
| LDAP SSO Identifier Field Value | A system field used to map the correspondence between users from AD and those from sso |
| API Token | This is the “Barer Token” for access to Deepser’s A.P.I. (Application Programming Interface) To go to the course Deepser’s A.P.I. click here |
| Empowered | Indicates if the user is an Empowered user, Empowered users are end users who are not limited to seeing only tickets for which they are requesters or whose company is the requesting company. |
Once you have filled in the fields, you will need to click on the “Apply” or “Save” button.
After you have created the user you can add it directly in a group by going into the ‘’Groups’’ tab(1) and clicking Add(2).
In the following screen that will open, you will have to check the group(s) that you want the user to be added to(1) and select the action add and then submit it(2).
Then you simply have to close the window and the groups the user is included in will be shown in the “Groups” Tab.
Another way to create a user is directly from an operation(ticket). To do so go to the Service(1) Module and afterwards go inside a ticket.
To create a new user you have to click on the user+ icon at the Requester fieled(2) and a window will pop up. All you have left to do is fill out the necessary fields explained at the table above.
Another case is when the ticket is created with an email, without a user, like this.
All you have to do is click on the user+ icon at the Requester Field and at the window that will pop up, the email field would be automatically filled for you, so you have to complete the rest of the fields.
Note: On user creation, the default role will always be “Users” (in “Role” field), which identifies an end user. Remember to change the role according to your needs. You can check available roles here.
To create a user from the CRM Contacts, you will have to go to the CRM module and then Contact (1). At the page that will open you have to click on the Add Contact Button on the top right of the screen(2).
Then you have to fill out the fields of the Contact Data.
The meaning of the fields is as follows:
| Camp | Description |
| Name | Name of the Contact |
| Surname | Surname of the Contact |
| Salutation | Allows you to Pin the greeting with which Refer to the contact (e.g. Lady or Miss) |
| State | Enable or Disable L Account |
| Department | The Department to which the Contact belongs |
| Qualification | The status of the Contact |
| Manager | Allows Specifying a Contact Manager |
| Source | Indicates the source from which the Lead was generated |
| Rating | Customer Account Satisfaction Level |
| Associate user | Allows Associating Contact to a System User on Deepser |
| Task | Task Related to Contact |
Afterwards you have to complete the information of the user at the Contacts tab and fill out the fields.
The meaning of the fields is as follows:
| Camp | Description |
| Email of the Contact | |
| Telephone | Number of Fixed Telephony |
| Mobile phone | Number of Mobile Telephony |
| Fax | Fax of the Contact |
| Address | Address of the Contact |
| City | City of Contact |
| Province | Province of Contact |
| CAP | Cap of the Contact |
| State | State |
After you have saved the newly created contact, you have to Sync it to a user. You have to go inside the contact and click on ‘Sync User’ on top right of the screen.
In order to change the password any account, you will have to go to
System->Permissions->Users and click on the user’s account you want to change the password to.
Here you can set the new password at the “Password” field (1) and confirm the password at the “Password Confirmation” (2) and simply save the changes (3)
To reset password of an account you will need the email address and the username of the user you want to reset the password. In the login screen you can see at the bottom of the login ‘Forgot your password?’.
By clicking there you will be redirected to the page where you can reset your password.
In this page you should provide username and email address of the account. After you provide the required data click the button ’Recover Password’. If the email address and the username correspond to an user in Deepser a new email should arrive at the email address provided. The email should look like the one given below:
If you click the Reset Password button or link you will be redirected to a new page where you can add your new password.
The criteria for the new password are:
After adding the password and clicking Reset Password button the password will be set to the one you provided and you will be redirected to the login page.
In Deepser it is possible to implement a user registration procedure to allow new users to register independently among the users present in Deepser.
Below, we will cover the procedure necessary to implement the creation of a registration form in Deepser.
Deepser allows you to create a registration form by combining one or more Step components.
To create a “Step” you will need to go to the “System -> Permissions -> user Registration -> Step” menu
In the screen that will open, you will need to click on the “Add Step” button.
Once you click the button, you will be redirected to the creation screen of a new step.
Below we briefly report the meaning of each field:
| Field | Description |
| Name | Step name |
| Position | Position in the step grid. |
| Label | Written that will appear to users when the step is uploaded. |
| Is Default step | Indicate if this is the step from which the recording will begin |
| Is Final step | Indicate if this is the step that will end the recording |
| Next step | Next step in the registration, null if the current step is the step that will end the registration |
| Check Token | Checks whether the verification token is present in the request. |
| Send Token | Submit the verification token |
| Token Duration | Token duration in hours and minutes |
| Mailbox | Indicates the mailbox with which the messages will be sent to the user during registration |
| Email Event | Email event associated with registration (if any) |
| StepData Formtemplate | Form template associated with the current step |
| Validate Expression | Custom code that allows you to validate the input data |
| Final Message | Final message that will be displayed by the user if the current step is set as the final step |
| Create User | Indicates whether a user will be created in this step |
| Create Active User | Indicates whether an active user will be created in this step |
| Send Reset Password | Indicates whether a password reset email will be sent to the user |
| Field Config | Mapping user principal fields to form template fields |
| User Create Expression | Custom code that will be used to create a user |
| Status | Indicates whether this step is active or not. |
In the successive lessons we will cover the creation of a registration form that allows a user to register himself and access the support, but only to users who belong to a company registered in Deepser, this to prevent external users from opening tickets without permission.
Before proceeding with the actual creation of the form, we must create a custom field that allows us to receive user input.
In the following example, we will see how to create a user only if the VAT number entered will correspond to one of the companies present in Deepser. For this example, we will assume that there is a custom field named “cust_vat_number” that will contain the VAT number of the company.
The Custom Fields will be addressed in another lesson, to go to the lesson related to the Custom Fields click here.
To create a custom field, we must go to: System -> Custom Fields.
Here we will have to click on the model “DeepRegistration – stepData”.
On the next screen, we will have to click on the “Add Field” button.
In the screen that will be displayed, will need to fill in the fields as follows:
Important is to set the “Column Type” and “Element Type” fields to text.
At this point, you will need to click on the “Save” button
Once this is done, we can proceed to implement the registration form.
In order to create the Registration Form we must go to the step creation menu to create a new step.
The Step Section is located under the “System-> Permissions – > user Registration -> Step” menu.
At this point, we give a name to our registration form by entering the desired name in the “Name” field
We define the “Position” field as zero.
Now we set the label that will be displayed on the registration screen by entering the desired text in the “Label” field.
Note that this field can contain text or even html with its css styles.
We define “Is Default Step” field to yes, in this way we are defining what will be the step from which the registration will begin.
Since in our example we have only one registration step, we also define “Is Final Step” to “Yes”.
Since in our example we have only one registration step we define “Next Step” as none, in the case of a multistep registration it will be possible to set what will be the next step, through this field.
Another important thing to notice is that to populate the field, you will first need to create a new step.
We set what will be the email box that we will use to send any Password change emails through the “Mailbox” field
Now we set which form template we want to display during registration using the field “StepData Formtemplate”
In the “Validate Expression” field, we can go to define the custom code that we will need to carry out checks on the validity of the data passed in input.
Within this field we are going to enter the following code:
/**Defining Variables**/
//Assigning StepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value og the cust_vat_number field to a variable.
$vatNumber = $stepData->getData('cust_vat_number');
//Assigning the value of the email field to a variable.
$email = $stepData->getData('email');
//if the email isn't in a valid format return an error to the user.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$this->addError("Email is not in a valid format");
}
//Retriving form the user collection all the users the have the username equivalent to the ginven e-mail.
$usersCollection = Deep::getResourceModel("deep_admin/user_collection")->addFieldToFilter("username",["eq" => $email]);
//Retriving form the user collection all the StepData the have the username equivalent to the ginven e-mail.
$stepDataCollection = Deep::getResourceModel("deep_userregistration/stepdata_collection")->addFieldToFilter("email",["eq" => $email]);
//If uone or more user or StepDatas where found retun an error to the user.
if($usersCollection->count() || $stepDataCollection->count()){
$this->addError("Email Already Registered");
}
/**If the company is present in Deepser we allow the registration otherwise throw an error**/
//Loading a company ginven the cust_piva field, if there is non company with this field this method retrive a new object.
$company = Deep::getModel("deep_company/company")->load($vatNumber,'cust_piva');
//If the returned object doesen't have the id or is null,return a error to the user.
if(!($company && $company->getId())){
$this->addError("We are sorry, but only employee of our customer can register an account");
}
In the field “Final Message” we will define the message that we will give to the user once the registration has been successfully completed.
Here, we will insert the following code:
<style>
.cust__msg{
margin-left: auto;
margin-right: auto;
display: flex;
flex-direction: column;
}
.cust__msg > *{
text-align: center;
box-sizing: border-box;
margin-left: auto;
margin-right:auto;
width: 100%;
}
.cust__msg .row{
display: flex;
justify-content:space-evenly;
padding-right: 30%;
padding-left: 30%;
}
</style>
<div class="cust__msg">
<h1>Success</h1>
<p>Congratulations, your account has been created!.</p>
<div class="row">
<div class="col-sm-3">
Username:
</div>
<div class="col-sm-3">
<?php echo $this->getStepdata()->getData('email');?>
</div>
</div>
<div>
<h6>We have sent you an email with the link to reset your password.</h6>
</div>
</div>
At this point, we will have to define to create a user by defining the field “Create User” to”Yes”.
Now, we will define if the user will be an active user by defining the field “Create Active User” to “Yes”
Now we will define whether to send the user an email at the end of the procedure that will allow him to reset the password using the “Send Reset Password” field.
Now, in the “Field Config” field we will define the mapping of the user template fields with the form fields. To add a new field to map with the form data simply click the “+” button.
We have defined the users’ field as follows:
In the “User Create Expression” field, we can define custom code that will allow us to set the user’s attributes or in general to perform actions when creating a new user.
In this field, we will enter the following code:
//getting the datas from the form
$stepData = $this->getStepdata();
// assigning the end user role to the created user by passing the role id
$this->getUser()->setData("role",73);
Finally, we set the “Status” field to Enabled (If it wasn’t already set to Active).
At this point, you will need to click on the button “Save” or “Apply”
To modify the form template that will be displayed during registration, you will need to click the “Preview” button
At this point, you will need to click the pencil button:
And then go to the StepData tab:
Here you can enter the fields by dragging them from the right column into the grid
Finally, you will need to click on the Save Button.
During the registration phase it may be necessary to validate the user’s email, to do this you can send a token that will allow you to verify the user’s email.
Taking as a basis the previous example, we create another step, this time ignoring the part related to the creation of the account, in addition we will configure the sending of the token.
In order to send the verification token to the end user it will be necessary to create an email event with its associated template form that will be used by Deepser to send the email to the user who is registering.
To create a custom mail event you will need to go to the System -> Tools -> Email -> Templatemenu.
Then you will need to click on the “Add MailTemplate” button.
In the screen that will open you will need to define a name for the template, to do this, simply enter the desired name in the “Name” field.
Next, we will define a code for the template, filling in the “Code” field.
At this point, it will be possible to insert in the “Subject” section the php code that will compose the subject of the email.
You can use the following code as a reference to compose the subject of the email:
<?php echo Deep::helper('deep_email')->__('DEEPSER - Confirm your Registration')?>
Now it will be possible to insert in the section “Body”, that will represent the content of the message, the PHP / HTML code that will serve to generate the body of the mail.
You can use the following code as a reference when creating the body:
<?php
$username = $this->getModel()->getEmail();
$firstname = trim($this->getModel()->getFirstname());
$lastname = trim($this->getModel()->getLastname());
$tmpFullname = $firstname . $lastname;
$fullname = $fullanme != "" ? $tmpFullname : "user";
$url = $this->getModel()->getTokenStepUrl();
?>
<?php $this->includeTemplate("header") ?>
<!-- Start of Main Content -->
<tr style="">
<td bgcolor="#FFFFFF" align="center" style="">
<table width="100%" align="center" cellpadding="0" cellspacing="0" border="0" class="devicewidth" style="">
<tbody style="">
<!-- Start Spacer -->
<tr>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td class="h26" height="36" style="font-size:1px; line-height:1px;"> </td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
</tr>
<!-- End Spacer -->
<tr style="">
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td class="mktEditable content mktEditable content" id="edit_text_1" valign="middle" style="font-family:Calibri, Helvetica, sans-serif; font-size:16px; color:#505050; text-align:left; line-height:25.6px; font-weight:normal; text-transform:none;">
<p>
<br>
<?php echo Deep::helper('deep_email')->__('Dear %s',$fullname);?>,<br>
<?php echo Deep::helper('deep_email')->__('Please confirm your registration by clicking the link below'); ;?><br>
</p>
</td>
</tr>
<!-- Start Spacer -->
<tr>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td height="30" style="font-size:1px; line-height:1px;"> </td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
</tr>
<!-- End Spacer -->
</tbody>
</table>
</td>
</tr>
<!-- End of Main Content -->
<!-- start of Button -->
<tr style="">
<td bgcolor="#FFFFFF" align="center" class="mktEditable" id="edit_cta_button" style="">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td class="w22" width="41" style="font-size: 1px; line-height: 1px;"> </td>
<td align="left">
<table class="button" cellpadding="0" cellspacing="0" border="0" align="left" bgcolor="#0080ff" style="-webkit-border-radius: 4px; -moz-border-radius: 4px; border-radius: 4px;">
<tbody>
<tr>
<td width="518" align="center" valign="middle" height="65">
<span style="color: #ffffff; text-decoration: none;">
<a class="mobButton mktNoTok" href="<?php echo $url ?>" style="font-family: Calibri, Helvetica, sans-serif; font-size: 16px; color: #ffffff; display: block; height: 65px; mso-line-height-rule: exactly; line-height: 65px; font-weight: normal; text-decoration: none; text-align: center!important;" target="_blank" title="Link al ticket">
<?php echo Deep::helper('deep_email')->__('Confirm the registration')?>
</a>
</span>
</td>
</tr>
</tbody>
</table> </td>
<td class="w22" width="41" style="font-size: 1px; line-height: 1px;"> </td>
</tr>
</tbody>
</table>
</td>
</tr>
<!-- end of Button -->
<?php $this->includeTemplate("footer") ?>
And click on the “Save” or “Apply” button:
To create a custom mail event, you will need to go to the “System -> Tools -> Email -> Event” menu.
At this point, you will need to click on the “Add Event” button.
The following page will be displayed:
At this point, it will be necessary to give a name to the event by filling in the “Name” field.
We define Whether to send attachments, changing the value of the field “Send Attachments”, in our case we set it to “No”.
Now, in the “Email Template” field, we select the template created in the previous point of this guide.
In the “Event Trigger”section, select “DeepUserregistration-StepData” in the “Model” field
In the “Event Expression” entry.
We insert the following code :
return true;
In the “To” section
We insert the following code :
/**Configuring the language with local **/
$this->changeLanguage($this->getModel()->getCustLocale());
/**Getting the email from the current model**/
$this->addTo($this->getModel()->getEmail());
At this point, we can go to click the “Save” or “Apply” button
Now the event will have been saved.
To create a new form template, you will need to click on “Preview”.
Here, you will need to click on the button with the arrow icon.
Now you will need to click on “New Formtemplate”
In the screen that will open, you will need to enter in the field “Enter Template Name” the name of the new form template.
Next, you will need to click on “Save”.
At this point, the new form template will be created.
To create a new form template, you will need to click on “Preview”.
Here you will need to click on the button with the pencil icon.
Here you will need to go to the “Fieldset”: “Step data”.
At this point it will be necessary to locate the field that we want to make mandatory and click on the corresponding gear icon.
In the screen that will open you will need to change the field “Required” and set it to “Yes”.
Now you will need to click on the “OK” button on the field configuration screen.
Finally, you will need to click on the “Save” button in the form configuration window.
At this point the field will be mandatory.
Deepser evaluates form templates from the highest priority to the lowest priority form templates.
The priority of the form templates is therefore important to define which form template the user will see.
To set the priority, you will need to go to the arrow key.
Now click on the template you want to edit.
At this point, click on the button with pencil icon.
Now you will need to click on the “Edit Rules” button and then subsequently set a value in the priority field.
Finally, click on the “Save” button.
For this example we will use as a basis the step created in the previous lessons, in addition we will create two form template the first named “First” with the email fields, Firstname and Lastname and the second named “Second” with only the Vat Number field (cust_vat_number) created in the previous points of lessons of this guide.
Let’s go to the Step section and click on the “Add Step” button
In this new we are going to configure the field “Name”, in this field we will enter the name we want to give to the step.
We configure the field “Position” to 0
We configure the field The “Label”, this field will contain the inscription that the user will see when he arrives at this form.
We configure the field “Is Default Step” to “Yes”.
We configure the field “Is Final Step” to “Yes”.
We configure the “Next Step” field on the step created in the previous points (User Support Registration).
We configure the field “Check token” to “No”.
We configure the field “Send Token” to “Yes”.
We set the “Token Duration”field, to an hour or at least to the time that we believe to be sufficient to perform the registration.
We configure the”Mailbox”fieldwith the exit mailbox that we will use for registraction.
We configure the “Email Event”fieldwith the mail event created in the point above.
At this point we set the field”StepData Formtemplate” form template that we want to use in this first step, in the template form we set all the fields that must be filled in as mandatory, in this way the user will have to fill them in order to continue, you can refer to the previous topic for the configuration of the form field as mandatory click here to go to the guide.
To create a custom form template you can follow the guide found in the previous article, click here to go to the guide.
We can configure the fields “Create User” and “Create Active User” to “No”.
In the “Validate Expression” field, we insert the following code to verify the form template.
/**Variables Initialization**/
//Assigning the stepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value of the email field to a variable.
$email = $stepData->getData('email');
/**Verifications**/
//if the emil isn't in a valid format return an error to the user.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$this->addError("Email is not in a valid format");
}
//Retriving form the user collection all the users the have the username equiva-lent to the ginven e-mail.
$usersCollection = Deep::getResourceModel("deep_admin/user_collection")->addFieldToFilter("username",["eq" => $email]);
//Retriving form the user collection all the StepData the have the username equivalent to the ginven e-mail.
$stepDataCollection = Deep::getResourceModel("deep_userregistration/stepdata_collection")->addFieldToFilter("email",["eq" => $email]);
//If uone or more user or StepDatas where found retun an error to the user.
if($usersCollection->count() || $stepDataCollection->count()){
$this->addError("Email Already Registered");
}
In this case we can leave the field “Field Config” as we are going to manage the creation of users in the last step
We can leave the”User Create Expression”field blank because we will not create users in this step.
At this point, Click on the Apply or Save button.
In the end, the step will be saved.
Let’s move now on to the final registration step.
In this step, we are going to change the”Check Token”field by setting it to “Yes”.
And we will configure the form template that will be associated with this template using the field “StepData Formtemplate”.
At this point, we modify the Form Validate Expression field to perform the only validation of the “Vat Number” (in the case of example).
**Defining Variables**/
//Assigning StepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value og the cust_vat_number field to a variable.
$vatNumber = $stepData->getData('cust_vat_number');
/**If the company is present in Deepser we allow the registration otherwise throw an error**/
//Loading a company ginven the cust_piva field, if there is non company with this field this method retrive a new object.
$company = Deep::getModel("deep_company/company")->load($vatNumber,'cust_piva');
//If the returned object doesen't have the id or is null,return a error to the user.
if(!($company && $company->getId())){
$this->addError("We are sorry, but only employee of our customer can register an account");
}
Note: this form template must have a higher priority than all the others
At this point, you will need to click on the “Save” or “Apply” button.
To enable the possibility of registering through the registration form, it will be necessary to go to the System -> Configurations -> Admin -> Security menu.
Here you will need to change the field “Enable User Registration” and set it to “Yes”.
Now, to save the changes, you will need to click on the “Save Config”button.
At this point, the registration link will have appeared on the main Login page:
Deepser natively supports integration with the LDAP protocol.
LDAP is a protocol for centralized resource management.
Deepser’s LDAP integration allows you to easily import users and or groups containing users that you will need to be enrolled to be managed/enabled in Deepser from an existing LDAP installation.
Note that Deepser synchronizes resources with LDAP in read-only mode and can independently manage the update of states or generally modified parameters on the LDAP Resources placed in the LDAP controller, this translates into the fact that if a user is moved to group or disabled or in general changes are made to the user on the LDAP controller the same changes, in a standard case, will be replicated on Deepser.
To configure an LDAP integration on Deepser you will need to go to the System -> Permission -> LDAP Integration menu
In the screen that will open, you will be able to view the LDAP integrations already configured and configure new ones.
To configure a new integration, you will need to click on the Add LDAP button.
After that the following screen will open:
Below are the fields present and their meaning:
| Field | Description |
| Show In Login | This field indicates whether this LDAP integration will be visible on the login page |
| Is Default | Indicates whether this LDAP integration will be the one selected by default in the list on the login page |
| Name | LDAP Integration Name |
| Domain Controller | The address at which to find the domain controller. |
| Cron Expression | Cron expression that indicates how often the integration will be performed. |
| Status | Indicates whether this integration is active or not, if it is not active the synchronization will not be performed. |
| Base DN | Domain base name, this field indicates the point below which Deepser will have visibility in the domain forest. |
| Time-out | Indicates the maximum time within which if a request is not answered, the request must be considered expired. |
| Use SSL | Indicates whether the domain controller uses S.S.L. encryption |
| Use TLS | Indicates whether the domain controller uses T.L.S. encryption |
| Follow Referrals | This field indicates whether to follow the referral links generated by the LDAP controller. Referral links are links that indicate that the server you are querying does not directly own the requested resource, but has a reference to the server or domain that owns that resource. |
| Admin Username | Username of the user that Deepser will use to read domain’s users. |
| Admin Password | Password of the user account that Deepser will use to read access the Domain Controller. |
In the Users Configuration section, you will define how users will be synchronized in Deepser.
Below are the fields in this section and their meaning:
| Field | Description |
| User Name Attribute | Indicates which field of the response obtained from the domain controller will contain the user’s name |
| User RDN Attribute | This field is the field that indicates the path relative to another entity (parent) of the resource in the Domains Forest . ES: distinguishedname. |
| User Fields | This field is used to map the relation between domain user’s fields and user’s fields in Deepser |
| User Object Filter | This field is used to specify an LDAP query, this will serve as a filter to retrieve only users who match the search criteria. |
| Account Prefix | Account prefix e.g.: “EXAMPLE\<username>”. In this case “EXAMPLE\” is the account prefix. |
| Account Suffix | Account suffix ex: “<username>@example.local”. in this case “@example.local” is the account suffix. |
| Disable Users | This field indicates whether users created on AD as disabled should be imported as disabled or not. |
| Custom Code | Custom code to indicate how user field values imported from integration are assigned. |
In the Groups Configuration section, you will define how groups will be synchronized in Deepser.
Below is a list of the fields present and their meaning:
| Field | Description |
| Group Enable | This field is used to enable the import of groups into Deepser from the forest. |
| Group Base DN | Indicates which is the name of the base domain in which the groups reside (e.i.: cn=exemple, dn=com) |
| Group Name Attribute | Indicates which field in the object returned by the request to the domain controller will contain the name of the group. |
| Group Members Attribute | Indicates which field in the object returned by the request to the domain controller will contain the list of users who belong to the group |
| Group Object Filter | This field is used to specify an LDAP query, this will serve as a filter to retrieve only the groups that match the search criteria. |
| Group Fields | This field is used to bind domain group fields to group fields in Deepser |
Once the fields have been configured, you will need to click on the “Save” or “Apply” button.
At this point, by clicking on the “Check LDAP” button, you can check if the integration works correctly.
If the integration works correctly, a green banner will be displayed in the upper right corner of the page.
In case of error, you will see a red banner in the upper right corner of the page.
SSO (Single Sign On) is the technology that allows you to use delegated authentication to access Deepser.
In Deepser you can configure the sso using “Google” or “Azure” as the preconfigured provider.
Alternatively, you can also configure other delegated authentication providers using the Client OAuth configurations, but in this case you will need to manually configure the authentication parameters.
To configure a new ss integrationor you will need to go to the System->Tools->OAuth->Client menu
Here you will need to click on the “Add Client” button:
As a first step you will need to assign a name to the client and click on the “Save” button to get the “Redirect Uri” that will be needed to configure the provider->side SSO.
After that, you can continue the configuration.
In the screen that will open you will be able to implement the configurations to implement SSO.
Below are the fields with their meaning:
| Field | Description |
| Name | Identification name of the OAuth Client |
| Provider | OAuth provider. This field can take 3 values: Google, Azure, Generic. In case this field is set to Google or Azure it will be possible to ignore the configuration of the fields: {{Insert list of fields already configured}}. If the field is configured to Generic you will need to manually specify the configuration of the fields. |
| Type | This field indicates the type of Client that is configured. The possible types are: User, Mail or Calendar. The type to be used for sso providers is: user. The Mail type is used to indicate an OAuth client that will interface with a mail provider. The Calendar type Is used to interface Deepser with an OAuth provider that provides a Calendar service. |
| Client ID | This field must be enhanced with the client id that will be provided by the Delegated Authentication provider. |
| Client Secret | This Field must be configured with the client secret that will be provided by the delegated authentication provider. |
| Scope | This field indicates the scopes to which the client will request access to the resources. |
| Url Authorize | Authorization url. this parameter is the endpoint to call to obtain authorization this parameter must be provided by the authentication provider |
| Url Access Token | It is the ‘URL base’ to which the parameters are added to request the authentication token (post-authorization step). You do not need to compile it for Google or Azure providers, the default values will be used. |
| Url Resource Owner Details | Base url of the server responsible for managing resources. This parameter must be formed by the provider. |
| Proxy | This field, if enhanced, will use the proxy indicated to forward requests for Delegated authentication. |
| Verify | If you have configured a proxy you can enable or disable SSL check. You do not need to compile it for Google or Azure providers, the default values will be used |
| Status | This field indicates whether the client is Deepser enabled or whether the client is disabled. Please note that if the client is disabled Deepser will not use it nor will it display it among the usable clients. |
| Scope Separator Char | Scope separator character, indicates which character the provider uses to indicate the end of one scope and the beginning of another. |
| User Data Source | Users’s data source url. |
| Endpoint User Data | The endpoint to which Deepser will make requests to obtain user data. |
| Related LDAPs | Indicates whether LDAP integrations are connected to this client |
| Username Attribute | This field indicates the name of the object field returned by the identity provider that will contain the username. |
| User Fields | Maps the user’s internal attributes with those retrieved from the specified user data endpoint. You do not need to compile it for Google or Azure providers, the default values will be used. |
| User Create Expression | Scripting area that allows you to specify how Deepser should behave when creating a new user and how to synchronize this user on the sso provider. |
| User Update Fields | Scripting area that allows you to customize the update of a user in case it is modified on the sso provider. |
| User Update Expression | PHP script to customize a user’s update,in the case of an SSO integration, for example. It is not necessary to fill it in for the Email Box type. |
| Login Button Caption | Text that will be displayed on the login button that will be created on the deepser login screen. |
| Login Button Icon | Image on the login button that will be displayed on the Deepser login page |
At this point the client verification key will be displayed, it will be necessary to click the validate button.
At the end of this configuration, you will need to click on the “Apply” button
You will then be redirected to the login screen of the Delegated authentication provider you are configuring.
At the end of the wizard if everything went well you will be redirected to the Deepser OAuth client screen with a message that will indicate that the configuration has taken place successfully.
In case of errors on the same page the error message will appear at the top.
The Provisioning functionality allows you to automatically create in Deepser the users and groups registered within your Microsoft Azure environment, if the latter have been enabled for the SSO application.
Therefore, instead of being created/updated only at each login, it is possible to perform a synchronization between the users present in Azure who must log into Deepser, and the related User records in Deepser.
This functionality can be performed only once, by clicking on the “Provision” button at the top right (mainly used for testing the configuration), or even be scheduled to run several times a day by configuring the Cron expression.
To configure this functionality in Deepser, in addition to what is seen in the “Configure SSO” section, within an Azure SSO client, it will be necessary to go to the “Provisioning” tab and configure the necessary parameters.
Below are the fields with their meaning:
Field | Description |
Provisioning enabled | If toggled on, provisioning is enabled |
Provisioning Provider | If “Azure” is selected, |
Cron Expression | If “Azure” is selected, some specific fields will appear and others will become required |
Tenant ID | Azure Tenant ID. Required for Azure provisioning provider. |
User Provisioning Mode | You can select the way in which users will be synchronized. Required for Azure provisioning provider. |
Disable Users | If toggled on, local user status will be updated with provisioned user status. |
Disable Deleted Users | If enabled, if the provided user has been deleted, or does not match the filters, or is removed from the users assigned to the application, disables the relative users in Deepser. |
User Filter | If provisioning provider is Azure, write filters in query string format, ie: $filter=surname eq ‘Foo’ $filter=jobTitle eq null $filter=userPrincipalName in (“Foo”,”Bar”) $search=”surname:Foo” For documentation, see Microsoft Graph documentation |
User Group Filter | Only provision users which are members of these specific groups. Groups are filtered by the field specified in Group Name Attribute |
Group Name Attribute | Specify which group data attribute will be used as the name of the group. It is also the name of the group attribute to filter by in the User Group Filter and in the Group Filter.If no value is provided: Azure provisioning provider, will use displayName by default. |
Group Provisioning Mode | You can select the way in which groups will be synchronized. Required for Azure provisioning provider. |
Group Provisioning Enabled | If toggled on, groups will also be synchronized. |
In Deepser you can set up SSO using Azure as the default provider.
This article explains how to configure Deepser and Azure, to allow SSO and User Provisioning via Azure Account in Deepser.
It includes 3 steps:
Note: SSO Login can be configured only on HTTPS protocol.
To configure a new SSO integration you will need to go to the System >Tools >OAuth >Client menu
Here you will need to click on the “Add Client” button:
As a first step you will need to assign a name to the client and click and set the following fields as follow:
Then you can click on “Apply” or “Save” button.
After the saving you can be able to copy the “Redirect URI” from the following field:
The “Redirect Uri” will be needed to configure the provider->side SSO (Azure in our case).
So, the first step of Azure SSO Configuration in Deepser is concluded. The next steps will be Azure Configuration and then the completion of the configuration in Deepser.
In this step we can manage the configuration from provider side (Azure).
You will need to login as administrator to the Azure portal: https://portal.azure.com/.
Note: We recommend performing all configurations in incognito mode or in a browser without any active logins to Azure/Outlook 365 to avoid user conflicts during the configuration.
Search for app registrations and open it
You can proceed with a new APP Registration (API), by clicking on “New registration” button:
On App Registration we can proceed entering the following information:
Redirect URI as “Web” type (Previously generated and copied from Deepser Oauth Client)
In conclusion you can click on “Register” button.
You can now access your newly registered application and navigate to ‘Manage > Authentication’ from the menu.
From here, you can confirm that the correct Redirect URI is set under the ‘Web’ section, and enable the following tokens:
Under “Manage > Certificates & secrets” in the menu, you can create a secret. During the configuration process, you’ll need to set its expiration time and copy its value, which will be used later to complete the configuration in Deepser.
The copied secret value will need to be entered into the field “Client Secret” on the oauth client record in Deepser:
Notes:
Under “Manage > Token configuration” from menu you can set the following optional claim IDs by clicking on “Add optional claim”:
When adding the claims, remember to check the box for “Turn on the Microsoft Graph email, profile permission (required for claims to appear in the token)”:
Under “Manage > API permissions” in the menu, you can add the following permissions for Microsoft Graph and then run the “Grant admin consent” action:
Also at this stage, if you need to Provision user/groups in Deepser, you need to add permissions for:
Click on “Add a permission” to open the permission selection prompt:
Then select “Microsoft Graph” as API permission to use:
From that screen you can choose Delegate or Application permissions and use the search field for research the desired permission to add:
After adding all desired permissions, you can run Grant admin consent command:
Now you can switch to “Enterprise Applications” by searching for it in the global search:
Then search and access your new registered application clicking on it:
After access to it, go to its properties and change the following configurations:
To enable provisioning for users and groups in Enterprise Application you can add your desired users and groups:
Now that everything is configured in Azure, you can go back to the Oauth Client in Deepser.
Before going back to the Oauth Client in Deepser, we can note down all the Azure information to be used in Deepser Oauth client configuration. Below is a summary of the Azure information to be reported in Deepser:
The “Secret value” will be entered “Client Secret” field in Deepser (“General” Tab):
Notes:
The “Application (client) ID” will be entered “Client ID” field in Deepser (“General” Tab):
The “Directory (tenant) ID” will be entered “Tenant ID” field in Deepser (“Provisioning” Tab):
You can now return to the Deepser Oauth Client record to proceed with the completion of configuration.
If not already done, please configure “Provider” and “Type” field respectively as “Azure” and “User”.
Then we can proceed to set Client ID and Client Secret:
In the “Client ID” field, enter your “Azure application ID”, which you can find in the overview section of the app registration
In the “Client Secret” field, enter the value you copied earlier when creating the secret
In the “Users” tab, you will need to fill the highlighted fields:
In this tab you can specify field mapping between Deepser and Azure, and you can also populate other fields and perform processing in Deepser upon creating/updating a user via the User Create Expression and User Update Expression fields.
If you want to enable users and groups provisioning, you can do it from “Provisioning” Tab.
In the provisioning tab you will need to fill in the fields highlighted in the figure:
In the “Tenant ID” field, enter your “Azure Directory (tenant) ID”, which you can find in the overview section of the app registration (like the Client ID):
After completing the configuration, you can return on the “General” Tab, and click on the “Validate” button and check if the connection between Deepser and Azure works well.
Note: We recommend performing validation in incognito mode or in a browser without any active logins to Azure/Outlook 365 to avoid user conflicts during the configuration.
For doing this, you can copy validation URL directly from “Redirect URI” field:
By clicking the provision button, you can check the configuration, and the users/groups selected in the Azure app should now correctly imported into Deepser.
You can also configure a Cron Expression to automatically run the provisioning at scheduled times.
Also refer to this article, for a better understanding of the fields in this form.
Multi-factor authentication (MFA) is a security system that requires multiple forms of verification to authenticate a user’s identity and grant access to a system. Instead of relying solely on a password, MFA typically combines something the user knows (like a password) with something they have (such as a smartphone or email address for receiving a code).This layered approach significantly enhances security by making it harder for unauthorized users to gain access, even if they obtain one factor of authentication.
To go to the Multi Factor Configuration you will need to go to the
System->Tools->Multi Factor->Configuration
To create a new one you will need to Click on Add Configuration button on the top right of the screen.
The following screen will open:
Field Name | Description |
Name | Name of the Configuration |
Type | Type of the Multi Factor Authentication TOTP(APP) or Email |
Enable Groups | Groups that will be able to use Multi Factor Authentication |
Label | Configuration’s Label that will be shown on the app |
Status | Enabled or Disabled. Weather the session is enabled or disabled. |
Note: Both types of Multi Factor Authentication are suggested to be enabled in order to deal with unforeseen events(such as phone out of charge or unable to access email).
Email MFA(Multi Factor Authentication) is possible in Deepser. In order to enable it you will have to choose the type Email in the Multi Factor Configuration.
Field Name | Description |
Name | Name of the Configuration |
Type | Type of the Multi Factor Authentication TOTP(APP) or Email |
Enable Groups | Groups that will be able to use Multi Factor Authentication |
Status | Enabled or Disabled. Weather the session is enabled or disabled. |
Mailbox | The configured mailbox that will be used to send out the code via email |
Mail Template | The email template that will be received via email |
Token Valid Time | The time that the received code is valid for |
After all of the fields are completed, whenever you try to log in the code will be sent to the email of the account.
Now every time you try to log in you will have to enter the MFA code received via email.
Depending on how you have configured the email template, this is how it will look like on the email.
In case you fail to insert the code within the chosen Token Valid Time, the following screen will appear which notifies you.
Useful guides: Out-going mailbox , Email Templates , OAuth Client for Email Integration
In order to activate the MFA in deepser you will need to go to your account settings.
Afterwards you will need to go the Security tab.
To enhance security, Deepser utilizes multi-factor authentication (MFA), which integrates an additional verification step involving a secondary device, typically a mobile phone.
You can verify your identity using an authenticator app like Authy, Google Authenticator, Microsoft Authenticator. For this guide, we are going to use Authy.
Scan this QR code through the app; it will display a 6 digits code which you need to enter below to enable login by app.
Using Authy App, you will have to Add An Account and then scan the QR code shown on account settings of deepser.
After you have scanned it, you would be able to see the configuration settings you set before, which you can also change whenever you need to from deepser or through the app.
After you have saved the settings, the 6 digit code will appear on your mobile screen, which you are required to enter in the Account Security Field.
And after the correct code has been set, you have to click on Verify and the following screen will appear:
Now every time you try to log in you will have to enter the MFA code in the authentication app.
Please note that each verification code generated for Deepser’s multi-factor authentication (MFA) remains valid for 30 seconds, after which a new code is automatically generated.
Each request for log in is stored and saved in Deepser. You can view it by heading to
System->Tools->Multi Factor->Authentication Request.
Field Name | Description |
User | The user that requested to log in |
Session ID | Unique ID for each log in session |
State | Shows if the log in was verified or not |
Generated At | The date and time the request was generated |
Attempts | How many times did it take for the user to set the correct authentication code |
Last Attempt At | Date and Time the user last tried to log in |
Last User Agent | Web Browser or Application that was most recently used to access Deepser |
Last IP Address | Numerical Label of the most recent device network that was used to access Deepser |
Status | Enabled or Disabled. Weather the session is enabled or disabled. |
Once the Users are created, Deepser allows you to organize them into Groups.
Groups are intended as work groups of backend user (Key-User, Agent, Admin) or End-User. A user can be part of several groups.
In Deepser, through groups, you can manage two fundamental aspects: record assignment and visibility.
Once the group configuration is complete, records can also be assigned to groups.
For example, in the Service module, we can define the assignee group of a request.
Once the group has been selected, even the select-box with the users assigned to the record is automatically filtered according to the members of that group.
Deepser allows you to filter, according to the groups to which the user belongs, the resources he can access.
It also allows you to define which permissions (visibility, modification, deletion) on records have the different teams of users within the modules they can access.
To create new groups in Deepser, or manage existing ones, go to the menu item System-Permission-Groups. This menu is accessible only by Administrator role user.
At this point the main grid of the groups will be shown.
To add a new group click on the button (top right, circled in the picture) ‘+ Add Group‘.
At this point the group creation form will open.
The fields of the form have the following meaning
| Field | Meaning |
| Name | The name of the group, displayed inside the select-boxes and grids in the system. |
| Status | Indicates whether or not the group is active in the system. |
| The group email (if any), to send automatic notifications to the email box dedicated to the team. | |
| Level | The level of support of the group. It is a useful number for Service Desk measurements and automation. For example, if you want to measure the working time of all top-level support teams, set level 1 to all top-level support groups in your organization. |
| Company Visibility | A user who belongs to a group with this field enhanced sees only the data of his company or sub-companies. In the case of a user with User type, this field is by-passed, because the user sees only the data of his Company. Note: the same field is also present in the individual user form, so the system will first try to apply the setting at the user level; if it is not set, apply the setting at the group level. |
| Description | The description of the group. Data used to keep internal notes on the configuration or meaning of the group. |
To add users to a group, after you’ve created it, click on the Members tab, in the group configuration form.
At this point a grid (Relation Grid) will be shown, containing all users already present in the group (if the group has just been created it will obviously be empty).
Click on the Add button to open the popup with the list of users in the system.
To add one or more users to a group simply follow these 3 steps.
To remove users from a group click on the Members tab, present in the group configuration form.
At this point a grid (Relation Grid) containing the users present in the group will be proposed.
To remove one or more users from a group simply follow these 3 steps.
In Deepser companies are important to manage visibility as users with the exception of empowered Users will be able to see only tickets, there but more generally all entities only if they are assigned or belonging to the company of which they are part.
In Case a user is a business supervisor and he is assigned to the Additional companies he will see all the entities belonging or assigned to the Additional Companies.
Users whose company is the parent of other companies, think for example of a company that is the parent company, will be able to see the entities connected or belonging to the daughter companies if and only if the “Limit to Company Data” field is not configured in the user’s configuration to “Company Data”.
As mentioned in the introductory article of this lesson, companies have an important role in managing visibility.
In this article, we will analyze in the Deepser entities the ways in which the Corresponding Companies are associated.
Companies in Deepser can be both assignees of a ci and owners of a ci.
If the company is assignees of a ci (figure 1) then it means that the users of that company or of the subsidiary companies will be able to see and interact with that ci (place there is no limitation of visibility for groups defined at the level of cmdb).
If the company owns a ci (Figure 2), users of that company will be able to see and interact with the ci in question.
Note that the visibility of the ci is evaluated in “or“ between the owner companies and the assignee companies
Companies play a fundamental role in ticket management as they are evaluated by Deepser to determine which tickets will be viewed by a given user (End User), however if the user in question is not a Company Supervisor or an Empowered User and is an End User, it will only see the tickets created by him, also Agents, Key Users and even Administrators could be limited to view the company datas, in this case they will see only the tickets created by their company in the user portal and in the backend.
In Deepser you can associate a company with an account in the CRM, or create a company from a CRM account.
The Accounts in the CRM serve as an address book and allow you to enter contact information related to the company.
In Deepser it is possible to create contracts and associate them with a company, it can be the owner (Fig. 1) or assignee of the contract (Fig. 2), in this way it will be possible to automatically manage the costs related to a supplier company or the costs related to the assistance lines, for example it is possible to automatically manage the total number of hours of assistance and the total number of hours spent by a customer company.
For a more in-depth analysis of the contracts in Deepser please check the corresponding section of the documentation; to go to the corresponding section click here.
In Deepser you can create new companies by going to the menu: System -> Companies.
Here you can create a new company using the “Add Company” button
At this point, the following screen will open:
Below is the list of fields and their meaning:
| Field | Description |
| Parent Account | This field indicates which is the parent company of the company that is configured, if the company will not have any parents then you will need to set the field as empty. |
| Name | Name of the company you are configuring |
| Description | Description of the company you are configuring |
| Phone | Phone of the company you are configuring |
| Fax | Fax of the company you are configuring |
| Address | Address of the company you are configuring |
| City | City of the company you are configuring |
| Are | Status (geographical/political) of the company you are configuring |
| Country | Country of the company you are configuring |
| Zip Code | Postal Code of the company you are configuring |
| Notes | Notes about the company you are configuring |
| Email Domains | Email domains associated with the company. Through this field it is possible to associate one or more email domains so that if one never, is received from one of these domains it is associated with the correct company. |
| Logo | Logo of the company you are configuring |
| Primary Contact | User who will be used as primary contact by Deepser, this will be the reference user for this company |
| Status | Indicates if the company is active or not, if it is not active it will not be displayed among the possible choices in the Company comboboxes. |
At this point, it will be sufficient to click on the “Save” or “Apply” button to save the changes and create the company.
Parent Companies in Deepser are companies that are referred to as relatives in related companies and that do not have a parent company themselves.
Companies’ Supervisor users who belong to the parent company if not limited to viewing only company data will also have visibility on the entities that belong or are assigned to the subsidiaries.
A company can have only one parent company, while a parent company can have several subsidiaries companies.
To make a company a parent company, you will need to go to the System -> Companies menu.
At this point, we must enter into the modification of a company that will become a subsidiaries company.
At this point it will be necessary to modify the “Parent Account” field, here we will select the company that will become the parent company.
At this point, you will need to click on the “Save” or “Apply” button
Now the company will be saved.
In Deepser you can associate a domain with a company.
In this way, when Deepser receives an email from an unregistered user but with a domain associated with a company, Deepser will associate automatically that email with the correct company.
To add an email domain, you will need to go to the menu: System -> Company
At this point, we click on the company to which we want to associate the domain or domains.
To this point we go to the “Email Domains” field, here we click on the “+” button.
In the text field that will appear we enter the domain in the form: “domainname.ext” for example: “example.com”.
Now is possible to proceed in the same way for all the domains that we want to associate with this company.
Once finished, you will need to click on the “Save” or “Apply” button.
In the company will be saved, and the emails received from these domains will be associated with the company.
In Deepser you can create a company starting from an account on the CRM.
This allows you to automatically transform also reporting the data entered in the account in the company model.
Note, however, that not all fields are synchronized automatically, for example the custom fields are not natively reported, to overcome this you can define an advanced synchronization procedure that we will deal with in the next topic.
To synchronize a CRM Account with a company, you will need to go to the CRM -> Account entry.
Here, you will need to click on the Account you want to turn into a Company.
In the screen that will open, you will need to click on the “Sync Company” button located in the upper right corner.
In the popup that will open you will have to be asked if you are sure to proceed, you will need to click on the “Yes” button to create the company or on the “Cancel” button to cancel the operation.
At this point, the new company will be created.
Note that if there is already a company with the same name as the Account it will not be associated with the existing company, but another one will be created associated with this crm account.
In Deepser it is possible to configure an advanced Synchronization procedure that allows you to set in the created company the fields that the Standard synchronization process would not import (e.g. custom fields).
In this guide we will see how to implement this procedure through custom events, we will see the creation of a unilateral synchronization procedure that is, the updates will be implemented by taking the changes from the CRM accounts and transporting them to the companies.
Note that advanced synchronization is an extension of the synchronization process and onventional, not a substitute for it, so before the changes implemented in this guide take effect you will need to carry out the conventional synchronization process.
Before proceeding with the actual creation of the form, we must create a custom field that allows us to receive user input.
For custom fields will be addressed in a special lesson, to go to the lesson related to custom fields click here.
To create a custom field we must go to: System -> Custom Fields.
Here we will have to click on the desired model, in our example “DeepCrm – Account”.
On the next screen we will have to click on the “Add Field” button
On the next screen you will need to fill in the fields as follows:
Important to set the “Column Type” to text and the “Element Type” to text.
At this point you will need to click on the “Save” button
Once this is done we can proceed to implement the real registration form.
In the following example we assume that there is both on the model “DeepCrm – Account” and on the model “DeepCompany – Company” a custom field of type text containing the VAT number.
The field on the model “DeepCompany – Company” named ” cust_vat_number “.
The field on the model “DeepCrm – Account” named “cust_vat_number”.
Logically it is possible to define any field following this example as a starting point.
To implement create a custom event for advanced synchronization you will need to go to the menu: System- > Custom Fields.
Here you will need to go click on the “DeepCrm Account” template.
At this point it will be necessary to click on the “Events” item.
In the screen that will open you will need to click on the “Add Event”button.
Now the following screen will open:
Here we are going to fill in the “Name” field with the name we want to assign to the event.
We set the Type field to “After Save”.
Now fill in the “Method” field with the following code:
/** Verify if the account is synched**/
if($this->getSynced() && $this->getCompanyId()){
/**Load the company from given the company id**/
$linkedCompany = Deep::getModel('deep_company/company')->load($this->getCompanyId());
/**If the company exist and the company have an id set, set the sync data, otherwise, do nothing**/
if($linkedCompany && $linkedCompany->getId()){
/**Load the custom field from the Account and insert it in to the company**/
$linkedCompany->setData("cust_vat_number",$this->getData('cust_vat_number'));
/**After the valorization of all the fields call the method Save on the company object to update the ditas on the Database**/
$linkedCompany->save();
}
}
Finally, must click on the “Save Event” button or the “Save And Continue Edit” button.
Now when we are going to sync a company he custom fields that we have indicated will be synchronized.
In Deepser visibilities are managed through 4 main elements: The “Requester” field, Roles, Companies and Groups.
Below, we will cover each of these aspects in more detail.
The requesting field indicates who requested the Ticket, this field is used by Deepser to set the visibility of the Tickets for the End Users, unless the user is a Company Supervisor or an Empowered User.
In Deepser, roles are used to define which resources the user will have access to.
We can exemplify the concept of managed roles with vertical visibility in Deepser, that is, the visibility of the modules presented in the sidebar
The default roles in Deepser are:
| Role | Description |
| Administrator | Users administrators in Deepser, they have global access and bypass the limits of visibility in the backend, in addition to this they faculty to modify the grids and form templates. This is the only role that has access to the system configuration and the System tab). Note: Super Admin users are Administrators who have set “All” in the resource visibility section. This role is the only one that has access to scripting areas in Deepser. |
| Agents | These Users have the right to modify the grids and form templates, but they do not have access to the scripting areas or even to the modules placed in the System tab. For the rest by default they have global access to all other modules. |
| Key Users | These users are comparable to Agents users, but unlike them, they have no ability to modify any system configuration, including grids and form templates. |
| Users | These are the end users, by default, these users do not have access to the backend, but only to the end user portal. Since they do not have access to the backend they cannot change any system configuration or even see the tickets that have not been opened by them. If there is a need for an end user to see tickets not opened by himself it can be modified by setting it as a Company Supervisor, in this case the user will be able to see all the tickets that belong to his company. Alternatively you can configure the user as an empowered user, this will give him visibility even on tickets not belonging to his company. |
At Deepser, companies are very important for managing visibility.
In Deepser a company represents a company in reality, or it can represent a department (in the case for example of a very large and structured company).
Companies limit the visibility of tickets or entities to the extent that entities created and by a company are generally only visible to users of that company or users who have that company among the additional companies.
All users who try to open a ticket or generally interact with an entity that does not belong to their company would get the “Access Denied” error.
Groups in Deepser allow you to manage entity visibility for groups of users.
For each Deepser entity, it will be possible to define which groups will have visibility on that resource. For all other groups, it will not be visible.
It is also important to note that in addition to groups it is possible to specify on the resource also the pseudo group “All Groups”, as the name suggests this group makes the resource visible to all groups.
If a user belongs to multiple groups, one of which has visibility and one of which does not have it, then the resource will be visible.
In Deepser it is possible to manage the user visibilit on the entities through two additional systems: Roles and Groups.
The Roles allow you to manage visibility vertically, preventing the access access to entire modules (Service, CMDB, CRM etc.) or areas (System submenu) of Deepser.
The Groups instead allow to manage the visibility in a horizontally.
On them is based the visibility, for example, of:
You can configure specific rules for each group to manage the permissions that users have on Deepser entities.
The Permissions on which the rules can be defined are the following:
| Permission | Explanation |
| CREATE | Indicates whether the user can create records for a given entity. Normally, the conditions in this case are simply true or false or indicate whether a user can create that record. |
| READ | Indicates whether the user can view the details of records for a given entity. In this case, you can define custom expressions to filter visibility on certain record types. For example, we can define that users in a group can display Service Operations, but only those of a certain Service Type. Or we can define the scenario where a user group can only display the Service Operations assigned to the users in the group. |
| UPDATE | Indicates whether the user can edit records for a given entity. In this case, you can define custom expressions to filter the change for certain record types. For example, we can define that users in a group can modify Service Operations, but only those of a certain Service Type. Or we can define that a user group can modify only the Service Operations assigned to the users in the group. |
| DELETE | Indicates whether the user can delete (physically delete) records for a given entity. In this case, you can define custom expressions to filter the deletion for certain record types. For example, we can define that users in a group can delete Service Operations, but only those of a certain Service Type. Or we can define that a user group can only delete the Service Operations assigned to the users in the group. |
| GRID | Indicates whether the user can view records, in the grids, for a given entity. In this case, you can define custom expressions to filter the display for certain record types. For example, we can define that the users of a group can display in the grids only the Service Operations assigned to the users of the group. With this permission you can filter “upstream” the queries made by Deepser’s grids, filtering them for each specific user group and separating the visibility of your service records for individual teams. |
To configure permissions from the group configuration menu access the Rules tab.
A list of any rules already configured for that group will appear.
From here you can add new rules or remove already defined ones.
By clicking on the + button the form for adding a new rule will appear.
The form fields have the following meaning
| Field | Meaning |
| Model | Model on which to define a rule/permit. |
| Type | Type of permission for which define the rule: Create, Read, Update, Delete, Grid. |
| Expression | PHP scripting area where you can define the rule by code. |
| All | This option enables permission (Type), to all members of the current group, on all model entities. |
| Assigned to User | This option enables permission (Type), to all members of the current group, on all entities of the model (Model), of which the User is the Assignee User. |
| Assigned to User Groups | This option enables permission (Type), to all members of the current group, on all entities of the model (Model), which have the current group as the Assignee group. |
| User is Requester | This option enables permission (Type), to all members of the current group, on all entities of the model (Model), of which the User is the Applicant. |
Note1: if a group has no rules configured for some models then that group has read / display / write / delete privileges on all records of those models. For this reason it is always good to set the permissions within the groups whose privileges you want to restrict.
Note2: If a user belongs to several groups, which have different rules, the most restrictive one is applied, case by case.
It is possible to define using PHP code, rules for the management of permissions, from the simplest to the most articulated.
Once positioned in the Rules configuration form, expand the scripting area by clicking on the </> icon G Expression field.
Inside that you can define a rule using PHP code.
In this example you want a group of users to be able:
To accomplish this requirements, you need to define 5 distinct rules.
To allow users to “CreateService Operations” it is necessary to define a rule having Create Type, DeepService-Operations Model and than insert the following PHP code:
return true;
To allow users to “Delete only the Service Operations assigned to their user” it is necessary to define a rule on the DeepService-Operations Model withType Delete where verify the current user is also the assigned user of the operation.
To do this, insert the following code:
//retrieve the assigned user username
$assignedUsername = $model->getAssignedUsername();
//retrieve the current user
$currentUser = Deep::helper('deep_admin')->getCurrentUser();
//ticket has an assigned user and assigned user is the current user then allow delete action
if ($assignedUsername && $assignedUsername == $currentUser->getUsername())
return true;
return false;
To allow users in the group to “Modify Service Operations sent by a specific user group” it is necessary to define a rule on the DeepService-Operations with Update Type to verify that the Requester of an operation is a member of a specific group.
To do this, insert the following code:
//retrieve the requeter user obkject instance
$requester = $model->getRequesterUser();
//if requester user is member of customers group then allow the update action
if ($requester && $requester->isInGroup('Customers'))
return true;
return false;
To allow users to “View details only of the Service Operations assigned to their own user groupsyou need to define a rule on the DeepService-Operations Model of Type Read to verify that the current user belongs to the assigned group.
To do this, insert the following code:
//retrieve the assigned group id
$assignedGroup = $model->getAssignedGroupId();
//retrieve the current user
$currentUser = Deep::helper('deep_admin')->getCurrentUser();
// if the current user is a member of the assigned group then allow to view operation details
if ($assignedGroup && $currentUser->isInGroup((int)$assignedGroup))
return true;
return false;
In order to allow the users to “Display in the grids only the Service Operations assigned to the groups of which the members are member of” you need to define a rule on the DeepService-Operations Model of Grid Type to verify that the current user belongs to the assigned group.
In this case, acting on the grid, add a filter to the query that retrieve records from the database.
//retrieve the assigned user
$currentUser = Deep::helper('deep_admin')->getCurrentUser();
//add a filter to the DB query on assigned group
// assigned group must be in the array returned by $currentUser->getGroupIds()
$collection->addFieldToFilter(
'assigned_group_id', ['in' => $currentUser->getGroupIds()]
);
In Deepser, end users correspond to those users whose role is configured as users.
They have access only to the user portal and possibly, if enabled, to the public portal, only if enabled.
End users can see only the tickets opened by them, unless they are Company Supervisors or Empowered Users.
In the case of an End user who is also a Company Supervisor, he will have access to all the tickets of his Company and all the tickets of the Additional Companies unless the user is limited to the Company Data, in this case he will have access only to his Company Ticket.
End users can view the CI assigned to them or of which they are the owners and which they belong, in the case of Corporate supervisor users they will view all the CI of their company.
End users do not have the right to modify form fields or change the form currently displayed.
For the management of modules related to the End-User Portal, it is possible to intervene through configuration to change the display/management of the modules directly from the “Configuration” section of the “System” menu:
By clicking on “Portal Configurations” you will be able to manage the following modules:
For the visibility of the Activity module in the Deepser user portal, it is possible to act by configuration by going to “SYSTEM > Configuration > Portal – Configurations” and finally Activity, we will access the Deepser section dedicated to configuring the visibility of the Activity module on the portal side:
Inside we will find the following configurable fields:
Worklog visibility is based on the entity it relates to. If the user has visibility for that specific entity then he can also see the worklogs if added to the form template.
For the visibility of CIs in the Deepser user portal, we can act in different ways.
First of all, going to “SYSTEM > Configuration > Portal – Configurations” and finally CMDB, we will access the section of Deepser dedicated to configuring the visibility of the CMDB on the portal side:
From here we can act on the configuration:
Enable: Allows you to enable or disable the visibility of the CMDB on the portal side.
Enable Priority: Allows you to choose how you want to manage the visibility of your CIs on the portal side.
The selectable values will be:
Once the CMDB module display type has been enabled and configured, the display of individual CI records will be managed based on the following fields:
For the visibility of CRM modules in the Deepser user portal, it is possible to act by configuring by going to “SYSTEM > Configuration > Portal – Configurations” and finally CRM, we will access the Deepser section dedicated to configuring the visibility of the CRM on the portal side:
From here it will be possible to indicate which modules in the CRM section must be made visible on the portal side (Enable Account, Enable Contact, Enable Opportunities fields).
You can also specify which groups will be able to access these modules, or whether all users will be able to access them indiscriminately (by selecting All groups).
Once the CRM forms section is enabled and configured, the display of individual records will be managed according to the “Portal Visibility” field in the reference form. Then the records will be displayed respecting the value of the following fields:
For the visibility of the Knowledge Base in the Deepser user portal, it is possible to act by configuration by going to “SYSTEM > Configuration > Portal – Configurations” and finally Knowledge Base, we will access the Deepser section dedicated to configuring the visibility of the Knowledge Base module on the portal side:
Once the KB module view is enabled and configured, the display of individual records will be managed according to the “Portal Visibility” and “Kb Group View” fields present in the Knowledge Base record configuration:
In addition, it is possible to intervene on the visibility of a single article in the KB always through the “Portal Visibility” field present within the article:
If the “Portal Visibility” field is set to “Yes”, the knowledge base or article will be displayed on the portal side.
For the visibility of CRM modules in the Deepser user portal, it is possible to act through configuration by going to “SYSTEM > Configuration > Portal – Configurations” and finally Password, we will access the Deepser section dedicated to configuring the visibility of Passwords on the portal side:
From here it will be possible to enable the display of the Password module on the portal side through the “Enable” field.
You can also specify which groups will be able to access these forms or whether all users will be able to access them indiscriminately (by selecting All Groups) via the “Enabled Groups” field.
Once the Password module is enabled and configured, the display of individual records will be managed based on the following fields:
Anyway, an end-user can only save private passwords. So, all passwords saved from end-user portal couldn’t be visible in the backend, but there are available only for him.
For the visibility of approvals, in the Deepser user portal it is possible to act by configuration by going to “SYSTEM > Configuration > Portal – Configurations” and finally Approval, we will access the Deepser section dedicated to configuring the visibility of the Approval module:
Inside we will find the “Enable” field as configurable. If enabled, it will allow the use of portal-side approvals.
However, a requirement for using portal-side approvals is the use of end-user Empowered licenses.
Only these types of users will have the ability to use the approvals module.
For the visibility of Surveys, in the Deepser user portal it is possible to act by configuration by going to “SYSTEM > Configuration > Portal – Configurations” and finally Survey, we will access the Deepser section dedicated to configuring the visibility of the Survey module:
Inside we will find the following configurable fields:
The visibility of a single survey on the portal side will be managed based on the enhancement of the “Users” and “Groups” fields present within the survey.
For the visibility of the Activity module in the Deepser user portal, it is possible to act by configuring it by going to “SYSTEM > Configuration > Portal – Configurations” and finally Tasks, we will access the Deepser section dedicated to configuring the visibility of the Task module on the portal side:
Inside we will find the following configurable fields:
The visibility of the tasks will instead be based on the “Portal Visibility” field present within the task and which must be set to “Yes” to make the portal task visible and the related “Assigned User” and “Assigned Groups” fields to be enhanced according to the users or user to whom the task is to be visible.
For the visibility of the tasks of the project module, in the Deepser user portal it is possible to act by configuration by going to “SYSTEM > Configuration > Portal – Configurations” and finally Project, we will access the Deepser section dedicated to configuring the visibility of project tasks on the portal side:
Inside we will find the following configurable fields:
The visibility of the tasks will instead be based on the “Portal Visibility” field present within the task and which must be set to “Yes” to make the portal task visible and the related “Assigned User” and “Assigned Groups” fields to be enhanced according to the users or user to whom the task is to be visible.
An EEU (Empowered End User) is a licensed user who has access to specific features on the End User Portal, such as:
The license type in this case is different from the license for backend users of Deepser, as it can only be used for End Users who therefore have access solely to the customer portal.
You can check the available and active licenses directly from the main users’ screen in the Backend (System > Permissions > Users):
Setting an end user as empowered, can be done by setting to “Yes” the “Empowered” field on the User model formtemplate. The “Empowered” field is visible for User model with role of “End User“.
NOTE: You can set it to “Yes” only if you have the EEU license type available. Additionally, it can only be set for users with the “Users” (End User) role.
The Empowered End User can approve or refuse an approval process. As an EEU all the approvals will be visible through the user menu in the End Users portal.
After clicking “My Approvals” EEU will be able to see the approvals grid assigned to them.
You can find more details on how to use the Approval flow by referring to the dedicated article here.
When a user is configured as ‘Empowered,’ they gain expanded visibility access for operations and other models, in addition to the approval flow. This is achieved through the Access Users and Groups fields, which are available by default in the Operation model and allow for more granular control over user permissions and data visibility.
Company supervisors are end users who have visibility on all tickets of their company, thus bypassing the limitation of visibility regarding only the tickets requested by them.
Users can be created as Company Supervisors from the beginning, or they can be promoted later.
Below we will explain the procedure for promoting a user to a Company supervisor, to create a user from the beginning please refer to the guide regarding the creation of a user.
To promote a user to a company supervisor, you will need to go to the System -> Permissions -> Users menu
From here, it will now be possible to access the users’ editing by clicking on an existing user.
In the screen that will open select “Is Supervisor” and set the value from “No”
to “Company Supervisor”
At this point, click on the “Apply” button or on the “Save” button
Finally, the modified user will be a Company Supervisor.
Additional Companies are companies with which a user can be associated in addition to his principal company, to have visibility also on the tickets generated by these additional companies and to open tickets on behalf of third parties, in the event that he is a company supervisor.
If the user is not a company supervisor, he will be limited to seeing only the tickets assigned to him, but in the form templates where the company field is present, he can select either his company or one of the Additional Companies.
To add an Additional Company to a user you will need to go to the System -> Permissions -> Users menu.
At this point it will be necessary to click on the user we are interested in editing.
Once we have entered the modification of the user to whom we are interested in adding the additional company, we identify the “Additional Companies” field in the template form.
At this point, we click on the field and start writing the name of the company to filter the field.
In this case, the company will be “Acme International”
Once you have identified the desired company, simply click on it to confirm.
The result will be as follows:
Now you will need to click the “Apply” button or the “Save” button to confirm the changes.
At this point, the changes will be applied correctly to the user.
You can also extend ticket visibility by using the “Access Groups” field for portal end users.
To use this field, it will be necessary to include it in the operations form as it is not normally displayed:
The field in question, in fact, through the multiple insertion of 1 or more groups, allows a ticket to be displayed even to groups of users who normally do not have visibility.
On the portal side, the standard display of information is based on the “Requester” field or on the company to which they belong in the case of supervisor users. This field gives you the option to extend the view.
However, to use this feature you must comply with the following rules:
You can also extend ticket visibility by using the “Access Users” field for portal end users.
To use this field, it will be necessary to include it in the operations form as it is not normally displayed:
The field in question, in fact, through the multiple entries of 1 or more users, allows you to display a ticket even to users who normally do not have visibility.
On the portal side, the standard display of information is based on the “Requester” field or on the company to which they belong in the case of supervisor users. This field gives you the option to extend the view.
However, to use this feature you must comply with the following rules:
In Deepser the resources are basically the modules or service that Deepser makes available.
An example of the exposed resources is shown below.
The visibility of the resources in Deepser can be set up to the model level.
The user will only be able to see modules and resources that have been set as visible to the membership role.
This Course covers everything related to Deepser Activities, which is a comprensive term for Comments and Worklogs. You will learn everything related to Activities usage and advanced System Configuration.
With the term Activity, Deepser refers to some activities that can be done on tickets.
There are two types of activity, Comments and Work Activities, both of which are available, if configured, either in the Backend or in the Users portal.
Activities are a great way to track relevant information and communication regarding a ticket. They facilitate ticket resolution by providing an additional point of contact between operators and end users.
Comments are used in ticketing to connect users and groups related to the ticket itself. Through comments it is possible to communicate updates, useful information to close the ticket, or put in contact end users with operators.
This guide will explain how to place a comment on an Operation.
1 – It is possible to access the “Activities” section of Operations through the User Portal or Backend, if properly configured.
1a – Through the User Portal, simply select the Operation on which you want to add a comment from the right grid.
1b -Through the Backend it is necessary to open the Service module through the drop-down menu, and click All to visualize all the Operations. Finally open the Operation on which you want to add a comment.
2 – At this point, scroll down to the Activity section, here comments and Work Activity are visible, the Comments tab will already be highlighted by default.
2 – To add a comment, click on Add Comment
3 – The form for inserting a comment is shown below
The meaning of the fields is the following:
| Camp | Meaning |
| Visible on Portal | Specifies whether the comment should be visible in the user portal, thus to end users. |
| Created By | Indicates the creator of the comment, it is automatically filled with the current user who is commenting. |
| Description | The text of the comment, formatted with images and structures such as tables, etc. |
| Comment Attachments | Allows to attach files to the comment. Note: The files will not appear as ticket attachments, but only to the comment. |
4 – To save the comment, simply click on the green checkmark in the upper right corner.
5 – The comment will then be displayed under the ticket
For comments, it is possible to make advanced system configurations, to set options such as: in which temporal order to display comments, and to automate the change of status of an Operation when a comment is inserted.
These configurations are available in Deepser’s system configuration menu. To access in system configuration, you need to use Deepser’s backend dropdown menu, then System->Configuration->Activity->Configurations.
This is the section dedicated to the configuration of comments at system level
The meaning of the fields is the following:
| Section | Camp | Meaning |
| Order Comments | Comment order direction (creation date Asc/Desc) | Allows you to sort comments from least to most recent (Asc), or from most recent to least recent (Desc). |
| Changes Service Operations status when adding a Comment | Enabled | If set to yes, when a comment is added to a Service Operation, it will automatically change state if it meets some rules defined by the fields below. |
| Select New Status | Indicates the state in which the commented Operation is to change. For example, Taken over. | |
| Exclude Status | Operations in any state shown in this list will not be affected by this automatism. For example, if you only want to change Operations to New status, enter all other statuses in this field. | |
| Apply if Created By user is in Group | Allows to enable this automatism only to users member of some groups. For example, if the status change has to occur only when an operator enters a comment, select a group of Operators. | |
| Save Config | Allows you to save the current configuration. |
With the term Activity, Deepser refers to some activities that can be done on tickets.
There are two types of activity, Comments and WorkLogs, both of which are available, if configured, either in the Backend or in the Users portal.
Activities are a great way to track relevant information and communication regarding a ticket. They facilitate ticket resolution by providing an additional point of contact between operators and end users.
WorkLogs are a useful tool for tracking each individual activity performed to bring the ticket to closure. WorkLogs can also be used in reporting to provide a cumulative calculation of the total work hours per user, performed on a ticket.
This guide will explain how to create a WorkLog for an Operation.
1 – It is possible to access the “Activities” section of Operations through the User Portal or Backend, if properly configured.
1a – Through the User Portal, simply select the Operation on which you want to add a comment, from the right grid.
1b – Through the Backend it is necessary to open the Service module through the drop-down menu, and select All to visualize all the Operations. Finally open the Operation on which you want to add a WorkLog.
2 – At this point, scroll down to the Activity section, where comments and Work Activities are visible, and select the WorkLog tab.
2 – To add a WorkLog, click on Add Activity.
3 – The form for inserting a WorkLog is shown below
The meaning of the fields is as follows:
| Fields | Meaning |
| Started At | Indicates the day and time when this activity began |
| Status | Indicates the status of the Activity |
| Duration | Indicates the duration in hours and minutes of the activity , this parameter can be used in reporting to calculate the total working hours. |
| Description | The text with the description of the work activity, formatted with images and structures such as tables, etc. |
| Created By | Indicates the creator of the activity , it is automatically filled with the current user who is entering it. |
4 – To save the work activity, simply click on the green checkmark in the upper right corner.
5 – The result is as follows
To display WorkLogs in the User Portal, so that end users also have access to them, you need to make some system configurations.
These configurations are available in Deepser’s system configuration menu.
To access system configuration, you need to use Deepser’s backend dropdown menu, then System->Configuration->Portal->Configurations.
This is the section dedicated to the system configuration of WorkLogs
The meaning of the fields is the following:
| Camp | Meaning |
| Show Worklog | Makes worklogs visible in the user portal. The worklogs will be read-only, if ‘Add/Edit Worklog’ is set to No. |
| Add/Edit Worklog | Gives End Users the ability to insert worklogs, or modify those already present in tickets. |
| Save Config | Allows to save the configuration |
The global grid of work activities is a configurable grid that allows you to view all work activities. This can only be reached from the backend.
You can go to the grid from anywhere in Deepser in the following way:
At the top right you can find the 3 dots: by clicking on them you will see the Task item and the Work Activity item.
By clicking WorkLog then we will access the grid that if not configured will show the following fields:
| FIELD | NOTES |
| Action | Through a floating window, the entity in which the related work activity is contained is opened (for example, the ticket in which the activity is contained). Clicking inside the row instead opens in a floating window the work activity. |
| Model | A template that contains the activity of work (usually contained in operations, i.e., tickets) |
| Model Id | The id of the template in which the activity is contained. If the work activity is in a ticket, the Id of that ticket will be shown. |
| Visible to Frontend | Visibility of activity in the front-end. By default, work tasks are never shown in the user portal. |
| Started At | The date and time that indicates the start of the activity. |
| Ended At | The date and time that indicates the end of the task. |
| Duration | Duration of the activity. |
| Created By | The user who created the task. |
| Created At | The date and time that indicates the creation of the work task. |
| Updated At | The date and time that indicates the last change in the work task. |
You can access the global grid configuration for work tasks through the edit button below.
Inside we could choose which fields to display and which not:
To insert or remove fields from the grid, you can simply use the arrows at the ends of the fields.
To change the order of the fields shown you can use the Drag & Drop, then simply drag the fields.
By then clicking on one of the displayed fields, it is possible to define whether it is possible to make the field sortable, filterable and / or multifilterable in the case of a select field through the relative checkboxes.
Within the grid in which we are located it is possible to define the collection of work activities that must be retrieved and shown in the grid through the appropriate Query Builder.
For example, you can view only the activities that have been placed within the tickets by setting the following control in the Query Builder: Model equal DeepService – Operation.
Through the Massive Actions checkbox, you can activate the massive actions in the grid.
Massive actions allow you to modify one or more work activities through a grid selection. The massive action that is currently implemented by default is that of elimination.
NB: Elimination through massive action will result in a physical deletion to databases. Deleted work tasks can no longer be recovered.
Through the Enable Export checkbox, on the other hand, it is possible to enable the export of the data displayed in the grid in XLSX or CSV format.
Once the export is enabled, a field will be shown in the grid that allows you to choose the format in which you want to extract the work activities and a button to export them.
Through the export will be extracted in the desired format the data of the work activities that are shown in the grid.
At the click of the sexport, you will be shown a popup that will ask if you want to export the only work activities visible at the time of export or if you want to export all the work activities.
Some fields already present in the Work Activities may contain useful and convenient information to be displayed in the grid, in which, however, a brief configuration is required to make them actually usable.
In fact, we can see that if we want to view the contract or the contract line to which a work activity has been associated and we make the fields already available visible in the grid, some numbers will be displayed which will represent the ID of the relative entities.
To be able, for example, to view the name of the contract associated with a work activity, it is necessary first to go to the modification of the grid and make the Contract column visible.
It will then be necessary to click on the field just made visible and make a change on the type by setting it from Text to Options.
By pressing the </> key you can define custom PHP code for each column and change the printed value (Renderer) or change the options of a Field of type Options (Options).
In the Options field you will then need to enter the following custom code:
// retreive of the Contract collection
$contractCollection = Deep::getResourceModel('deep_contract/contract_collection');
// convert the collection into an associative array
// the key is the Contract Id and the value the Contract Name
$optionsArray = $contractCollection->toOptionHash();
return $optionsArray;
Similarly, to view the name of the contract line associated with a work activity it is necessary to make the Contract Line field visible, change its type in Options and within the Options field to define custom code insert the following code.
// retreive of the Contract Line collection
$lineCollection = Deep::getResourceModel('deep_contract/line_collection');
// convert the collection into an associative array
// the key is the Contract Line Id and the value the Contract Line Name
$optionsArray = $lineCollection->toOptionHash();
return $optionsArray;
At this point we may display the names of Contracts and Lines of Contracts that have been associated with the related work activities. We can also make these fields multifilterable and sortable.
It can often be helpful to set the same value to multiple tasks. In these cases, the use of mass actions is effective.
At the moment, the only massive action already prepared by the system in the grid of work activities is that for the (physical) elimination of one or more activities.
You can still configure a custom massive action by accessing the grid change. Below the Mass Action checkbox is the </> button that allows the opening of the custom PHP script area.
The following example shows the custom code that implements a massive custom action to enable or disable the visibility in the portal of one or more work activities.
The code must be inserted directly into the custom PHP script area.
// create the array for the option visibility
$visibilityArray = [0 => 'No', 1 => 'Yes'];
// initialize html component
$this->addMassActionItem('visibility', [
'label' => 'Visible to Frontend',
'additional' => array(
'visibility' => array(
'name' => 'visibility',
'type' => 'select',
'class' => 'required-entry',
'label' => 'Visible to Frontend',
'disable_js_select' => true,
'values' => $visibilityArray,
)
),
//callback is the method that contains the logic of the action
'callback' => function() {
/** @var Deep_Grid_Model_Grid_Massaction_Callback $this */
/** @var Mage_Core_Model_Resource_Db_Collection_Abstract $collection */
$collection = $this->getGrid()->getModelInstance()->getCollection();
//$this->getIds() returns the id of the selected activities
$collection->addFieldToFilter('entity_id', ['in' => $this->getIds()]);
// $collection contains the instances of the selected activities and we iterate on them
foreach($collection as $activity){
//$this->getValue() contains the id of the new option visibility, the selected one
//set the new activity visibility
$activity->setPortalVisibility($this->getValue());
//save the activity
$activity->save();
}
}
]);
By inserting this script, it will then be possible to select one or more work activities and decide whether or not to make them visible in the end user portal.
In Deepser, roles are used to define which resources the user will have access to.
We can exemplify the concept roles manage Vertical visibility in Deepser, that is, the visibility of the modules presents in the sidebar
The default roles in Deepser are:
| Role | Description |
| Admininstrator | Administrators Users in Deepser, are users that have global access and bypass the limits of visibility in the backend, in addition to them have faculty to modify the grids and form templates. This is the only role that has access to the system configurations and the System tab. |
| Super Admin | Super Admins are users with Administrator role who have set “All” in the resource visibility section. This role is the only one that has access to scripting areas. |
| Agents | These Users have the right to modify the grids and form templates, but they do not have access to the scripting areas or even to the modules placed in the System tab. For the rest by default, they have global access to all other modules. |
| Key Users | These users are comparable to Agents users, but unlike the latter they have no ability to modify any system configuration, including grids and form templates. |
| Users | These are the end users, as a rule, these users do not have access to the backend but only to the end user portal. Since they do not have access to the backend, they cannot change any system configuration or even see the tickets that have not been opened by them. If there is a need for an end user to see tickets not opened by himself, he can be modified by setting him as a Company Supervisor, in this case the user will be able to see all the tickets created by his company. Alternatively, you can configure the user as empowered user, this will give him visibility even on tickets not belonging to his company. |
In Deepser there is a “Board” module.
The Board module allows you to create custom Boards in Kanban Format.
Kanban is a framework for Agile development that allows you to visualize your workflow, focus on progress, and optimize efficiency.
Deepser Boards can be of 2 types: FreeForm or Live.
In this course we will analyze everything related to Deepser boards.
To enable the groups to see the boards it will be necessary to go to the menu: System -> Configuration
At this point you need to go to the Tab Board -> Configuration
From the “policy” tab it will be possible to configure which groups will have the possibility to create boards and board freeform.
In Deepser to create a new board of type FreeForm You will need to go to the menu: Board -> List.
To create a new board once you go to the Board -> List menu you will have to click on the “+” button at the top left corner:
On the page that opens set the type to “FreeForm”.
At this point you can configure the name field with the desired name and the Description field with the description that will be displayed in the new board.
At this point you can check that the status of the board is set to “Enabled” and click on the “Save” button to create the board.
At this point the new board will have been created.
To access a board you will need to go to the menu: Board -> List
At this point locate the board you want to view and click on the “View” button
To customize a board you will need to go to the menu: Board ->List, go to the three dots.
At this point it will be possible to add an icon by clicking the choose file button (3) or select a background for the board through the “background” or “background” selector (4), then click the “save” button (5).
For the logo it will now be present in the custom board.
To view the background you will need to go inside the board that you are customizing.
Deepser allows you to share a board in reading or reading and editing or reading, editing and interaction to allow you to make boards a very effective and immediate collaborative tool, suitable for the management of complex processes.
To share a board you will have to go to the menu: Board -> List.
From here you will need to click on the three dots placed on the board you want to share:
At this point the following screen will open:
The sharing fields are expressed in the following table.
| Field | Description |
| View Users | Users who can view the board read-only |
| View Groups | Groups that can view the board as read-only |
| View and Interact Users | Users who can view and move board items, but not edit or delete them |
| View and Interact Groups | Groups that can view and move board items, but not edit or delete them |
| View, Interact and Edit Users | Users who can edit the board, move the Entries and delete them |
| View, Interact and Edit Groups | Groups that can edit the board, move the Entries and delete them |
Note: In order to share a board it will be necessary that the user is registered with the system. In addition, in order for the user to view and interact with the board it will be necessary that he is a backend-enabled user and that he has a role where it is allowed to view the boards among the options in the side menu of Deepser.
A lane in Deepser is the entity within the boards that serves to contain and organize tasks in a logical way.
To create a Lane in Deepser you will need to go to the board where you want to add the wool, here you will have to click on the “+” button at the top right corner.
In the screen that opens you can set the name, filling in the “Label” field (2) and then click on the “Save” button (3).
Now the system will create the new Lane with the specified name.
To customize a Lane you will need to go to the Lane to customize and click the 3 points .
Here you can change the name or color of the Lane.
To change the name, simply edit the contents of the label field.
To change the color you will have to click on the color picker (2)
choose the desired color and click “save ” (3) and then the “Apply” button(4).
Finally, the Lane will be colored in the desired color.
To create a new entry in the boards you will need to go to the section: Board -> List:
Then you will have to go to the board where you want to insert the Entry, in our example “Board Name”
Here, click on the “View” button
Once you enter the board you will need to identify the lane where you want to add the Entry
After that it will be necessary to click the “+” button in corrispondence of the Lane in which you want to add the Entry
At this point you will have to give a title tothe new Entry and then click the tick button
At this point it will be possible to see the new entry in the lane.
To move an Entry to another Lane simply click on it and drag it to the new lane.
Once the Entry is released, the result will be as follows:
The Live boards in deepser are a particular type of board, that instead of the entries allows to organize at logical level the entities inside Deepser.
In this lesson we will analyze how to create, customize and manage Deepser’s Live boards.
In Deepser it is possible to create in addition to freeform boards also live boards.
Live boards allow you to manage Deepser entities in graphical mode by representing the individual entity as an Entity of a board.
To create a live board you will need to go to the menu: Board -> List
Here you will need to click on the “+” button:
At this point the board creation screen will appear.
Here we are going to select as board type “Live” and as Model Alias “Deep service Operation”.
Similarly to the freeform boards also in the live board will be possible to insert an icon, to do so it will be sufficient to click on the button
Next we click the apply button to save the changes
At this point the live board will be created by Deepser.
The end result is as follows:
Now the board is configured for basic usage.
By default is configured to retrieve a collection of all Service Operations. We will see in the next topic how to limit the number of Operations or in general entities of Deepser that can be recovered by applying filters to the collections of datas.
To configure the collection of a live board you will have to go to Board -> List
At this point you will have to go to the live board you want to edit and click on the three dots to access the configuration screen.
At this point you will have to go to the “Prepared Collection” section
Here it will be possible to configure which tickets will be viewable within the board.
For example, suppose you want to display only tickets in a new state or work in progress.
To do this, simply configure the query builder like this:
To finalize the changes you will need to click on the Apply button
In this article we are going to deal with two examples of configuration of advanced live boards.
In this example we are going to replicate the configuration of the data collection of the previous board but using the scripting area present in the board.
To create a live board you will need to go to the menu: Board -> List
Here you will need to click on the “+” button:
At this point, the board creation screen will appear.
Here we are going to select as board type “Live” and as Model Alias “Deep service Operation”.
Similarly to the freeform boards also in live Boards it will be possible to insert an icon, to do so it will be sufficient to click on the button
Next we click the apply button to save the changes
Now we have to go to the scripting area, like the one shown in the figure:
In the scripting area that will open we are going to insert the following code:
/* Only select tickets in New and Work in progress statuses**/
$this->getModelCollection() ->addFieldToFilters('status',["in"=>[1,2]]);
At this point we must go to click the save button to confirm the configuration.
In this example We are going to configure a live board that will load all the tickets for which the company of the requesting user has a flag set for priority assistance.
For this example we will assume that there is a “cust_prioritary_assistance” field in the company, of the checkbox type.
When the checkbox is flexed we will consider the company as a company with priority assistance.
To create a live board you will need to go to the menu: Board -> List
Here you will need to click on the “+” button:
At this point, the board creation screen will appear.
Here we are going to select as board type “Live” and as Model Alias “Deep service Operation”.
Similarly to the freeform boards also in live boards it will be possible to insert an icon, to do so it will be sufficient to click on the button
At this point we can go to add in the scripting section of the board the following code:
$this->getModelCollection()->getSelect()->joinLeft('deep_company_company','main_table.requester_company_id = deep_company_company.entity_id',[]);
$this->getModelCollection()->addFieldToFilter('deep_company_company.cust_prioritary_assistance', 1);
Now we must click on the Save button to save the board.
A Lane in Deepser is the entity within the boards that serves to contain and organize in a logical way the entities loaded by the board.
To create a Lane in Deepser you will need to go to the board where you want to add the wool, here you will have to click on the “+” button at the top right corner.
In the screen that will open you can set the name, filling in the “Label” field.
At this point you can enter a new field in the Field field to display. In this case we enter the field “entity_id”of the ticket. By clicking on the button
At this point we select in the Field field the value “entity_id” and in the label field “Yes”.
At this point you will need to click on the apply button.
Now the system will create the new Lane with the specified name.
The following properties of a lane can be customized: the name, the color of the Lane, the data collection, the Drop Code or the fields to be displayed for each ticket in that Lane.
To change the name, simply edit the contents of the label field.
Next you will need to click on Apply:
To change the color of the Lane you will need to go to the Lane to customize and click the 3 points.
Here you can select the color to assign to the Lane using the color picker:
choose the desired color and click “Save”:
and then the “Apply” button:
Finally, the Lane will be colored in the desired color.
In Deepser’s live boards Lanes the prepared collection section is used to define which tickets will be displayed in the Lane.
To customize the prepared collection of a Lane in a live board you will need to go to the Lane to customize and click the 3 points.
Now it will be possible to set the data collection to be displayed in that lane through the “Prepared Collection” section
Let’s say you want to display in this Lane only the entities in a state new, you can do it through the query builder:
At this point click on the “Apply” button:
Now the lane will be updated automatically by the system loading only the tickets that correspond to the filters set
The drop code in Live boards is the code that is executed when a ticket is dragged onto the board.
To customize the drop code of a Lane in a live board you will need to go to the Lane to customize and click the 3 points.
Here you will be able to set the code to run in the “Drop Code” section via the query builder.
In the current example, let’s say we want to set that when a ticket is dragged into this section it takes on a new state:
At this point when a ticket is dragged on this board, its status will change to new.
A Lane in Deepser is the entity within the boards that serves to contain and organize in a logical way the entities loaded by the board.
In this article we will see an example of advanced lane configuration using the scripting area on the lane and an advanced example of changing the Drop Code of a lane.
In this example we are going to show in the lane only the tickets in The New state, by default id 1.
To Edit a live lane you will need to go to the board where you want to change the wool, here you will have to click on the three dots:
At this point we will have to go to the scripting area “Data Collection (Script)” as in the figure shown here:
Here we are going to enter the following code:
/**Visualizing only the ticket in with state "NEW"**/
$this->getModelCollection()->addFieldToFilter('status',["eq"=>1]);
At this point click on the “Apply” button:
Now the lane will be updated automatically by the system loading only the tickets that correspond to the filters set
The drop code in Live boards is the code that is executed when a ticket is dragged onto the board.
To customize the drop code of a Lane in a live board you will need to go to the Lane to customize and click the 3 points.
In the current example, let’s say we want to set the company as a company with priority assistance when a ticket is dragged into this Lane.
To do this we insert in the scripting area “Drop Code (Script)”:
the following code:
/**Setting prioritary assistance for the company of the dropped ticket **/
$company = $this->getDroppedModel()->getRequesterCompany();
$company->setData('cust_prioritary_assistance',1)->save();
At this point click on the “Apply” button:
At this point when a ticket is dragged on this board its status will change again.
In deepser, roles are an important component in visibility management.
The roles allow you to manage the visibility of the modules accessible to user accounts (e.g. password, crm etc) or even which users can access the Deepser backend and which can only access the user portal.
To create a role in Deepser you will have to go to the “System the Permissions->Roles” menu.
At this point in the screen that will open you will have to click on the “Add New Role”
On the next screen you can set the “Role Name” field which will define the name that will have the new role.
In the type field it will be possible to define the Type that will have this role by compiling the “Type” field.
Then moving to the “Roles Resources” tab you can define which resources will be visible to the user to whom this role will be assigned by configuring the “Resource Access” field to Custom an selecting the resources you want to expose to this role.
Note: if you want to set the role to have no visibility limitations you can opt to select from the drop-down menu the item “ALL” instead of the item “Custom”, in this way no visibility limitations will be applied on the role (however this will not affect the visibility configured for groups).
Now click on the “Apply” or on the “Save” button.
Once the role has been created, a third item will appear in the list of tabs: Role Users.
Using this tab you can get a quick overview of all the users who have been assigned that role.
Categories in Deepser are an important tool for the management of Tickets, CIs, or the Deepser entities in general by backend side operators.
The Categories allow you to describe quickly and concisely the scope of that specification required, for greater flexibility Deepser allows you to organize the categories on a hierarchical scale of up to three levels which translates into being able to have a first level category with N categories of second level and each of them with N categories of third level.
Categories in Deepser are an important tool for the management of Tickets, CIs, or the Deepser entities in general by backend side operators.
The Categories allow you to describe quickly and concisely the scope of that specification required, for greater flexibility Deepser allows you to organize the categories on a hierarchical scale of up to three levels which translates into being able to have a first level category with N categories of second level and each of them with N categories of third level.
The categories in addition can be visible on one or more types of service or some categories can be visible only by some groups of users, this allows you to manage in a granular way the categorization of tickets, in addition they can be enabled and therefore visible or be disabled and therefore not displayed within the appropriate field.
In addition, they can be used as parameters in routing rules (Automatic assignment of tickets, these will be covered in a later lesson) to assign a ticket to a user or group based on the category.
So each first level category corresponds to zero or more second-level categories, and for each 2-level category zero or more third-level categories correspond.
This structure is called hierarchical because if you apply visibility restrictions on a higher-level category, the lower-level categories will inherit those limitations.
Categories in addition can be made visible for all models, by default, or only for a specific model.
To create a new category in Deepser you will need to go to the menu: System -> Categories
At this point, you will need to click on the “Add Root Category” button
At this point, the following screen will open:
Below are the fields with their meanings:
| Field | Description |
| Name | This field is the name that the new category will have. |
| Description | This field is the description that will be associated with the new category |
| Image | This is the icon that will be displayed side by side next to the category name (only if this field is filled in) |
| Status | This field is the status that will have the new category: if the status will be enabled then the category will be displayed among the usable and selectable categories, otherwise it will not be displayed among the categories. |
| Frontend Visibility | This field indicates whether this category will be viewable among the categories in the guest portal (only if the guest portal is enabled) |
Once you have filled in the fields, you can click on the “Save Category” button
To create a new subcategory in Deepser you will need to go to the menu: System -> Categories
At this point, you will need to select the category that will become the parent of the new subcategory and click on the “Add child Category” button
Now the following screen will open:
Below are the fields with their meanings:
| Field | Description |
| Name | This field is the name that the new subcategory will have. |
| Description | This field is the description that will be associated with the new subcategory |
| Image | This is the icon that will be displayed side by side next to the subcategory name (only if this field is filled in) |
| Status | This field is the status that the new subcategory will have: if the status will be enabled then the category will be displayed among the usable and selectable subcategories, otherwise it will not be displayed among the subcategories. |
| Frontend Visibility | This field indicates whether this category will be viewable among the subcategories in the guest portal (only if the guest portal is enabled) |
Once the fields have been filled in, it will be possible to click on the “Save Category” button.
On model visibility tab you can limit the usage and access of a category on a model. For example, you can set a category to be visible only on operation model.
To configure a new model visibility, just click on the ‘+’ button inside model visibility tab.
Below there is an example of a model visibility, that limits the ‘User Equipment’ category to only operations of type ‘Request’ and ‘Incident’. When users open a ticket of type ‘request’ or ‘incident’, they will be able to view and use the ‘User Equipment’ category.
Field | Description |
Model | Select field where you can choose the model which will have visibility to this category. |
Portal Visibility | With this field you can make the category visible or not on End Users portal. |
Frontend Visibility | Select field with Yes/No values , that can set the category visible on frontend portal. |
Expression | Query Builder field that adds another layer of visibility on the category. With this field you could limit the visibility of a category if certain conditions based on model’s fields, are met. |
Expression (Script) | Scripting field that has the same functionality as the query builder, but here you can write the conditions directly by code. |
By configuring group visibility you can limit, users access to a category based on the group that they participate.
To set group visibility, just go under group visibility tab and select the groups of visibility on the ‘Enabled Groups’ field. In the example below, the “User Equipment” category is visible only for users that are part of “IT- First Level” or “IT Customers” groups.
Here, you will need to click on the category we want to change.
At this point, we must change the field “Portal Visibility” to “Yes”
Finally, we must click on the “Save Category” button.
The usage of categories is available by default in Operation or CMDB models, through a custom field with element type ‘category’.
This is how to category field shows on the formtemplate after configured.
On the first select field there are shown all the Categories of level 1. After a first category is chosen the select of second categories is shown and so on.
Categories of different levels can be used on grids of the models that have the category field configured. To be able to display the categories fields in grids, fields should be dropped on the visible columns of grid. The column type should be ‘options’ , so that the category name is displayed and not its entity id.
After adding the categories this is how they will appear on the grid.
A user in Deepser is an individual who interacts with the system, utilizing its features and functionalities.
To create a new user in Deepser you will need to go to the menu System -> Permissions -> Users(1)
In the screen that will open, you will need to click on the “Add User” button(2)
At this point, the following screen will open:
| Field | Description |
| Avatar | Profile picture of the user. |
| Username | Username of the user, this will serve to log in, this is a mandatory field to create and in addition this field must be unique within Deepser. |
| Firstname | The name of the user. This is a required field |
| Lastname | User’s lastname. |
| User’s email | |
| Password | Password of the user, note that this field is always white because the user’s password is not stored in a database format that is invertible, consequently the field remains unvalued by default even if the user has a password set, except when changing the password itself. In case of changes to this field when saving the user Deepser will automatically update the value of the password present in db. |
| Password Confirmation | Confirm the user’s password, like the previous field, this is also not valued except when changing the password itself. |
| Role | The role of the user, depending on the role the user will have different visibilities on the various parts of the product. For example the Users role, who by default sees only the End User Portal. The roles of the users will be deepened in the dedicated Lesson, click here to go to the corresponding lesson. |
| Active | Indicates whether the user is authorized to access Deepser. If the value is “Active” the user will be enabled to access, if the value is “Inactive” then the user will not be authorized to access Deepser. |
| Startup Page | This field indicates which is the default page to which the user will be redirected after logging in. |
| Local | Indicates the language in which the user visualizes Deepser interface |
| Timezone | It indicates the time zone associated with that user, it is important to indicate the correct time zone so that Deepser can correctly set the format of the dates in notifications and date fields. |
| Company | The company field indicates which company the user belongs to, this field is very important since Deepser companies are one of the key elements in visibility management. The companies will be analyzed in the following lessons, click here to go to the lesson on the companies. |
| Additional Companies | Additional companies indicate to the data of which other companies the user will have access. This topic will be deepened in the lesson on company, this field will be selectable only after the user has been saved at least once |
| Is Supervisor | This field indicates whether the user will be a company supervisor. A company supervisor will have the ability to view and modify the tickets created by the users of his company |
| Company Visibility | This field indicates if the user will have limited visibility to Company Data |
| Portal CMDB Visibility | This field indicates if the user will see the cmdb in the user portal. |
| OTL Token | This token if passed as a parameter (token) in the url of the request (query string) allows you to access Deepser without logging in. Note that the setting of direct access by token is by default disabled for security reasons, in addition for security reasons this token has validity of only one use, after which it is automatically reset by the system, this is done to avoid data theft. |
| rp_token | This token is used to reset a user’s login credentials. This is a system field, at the operational level there is no use for this field. |
| LDAP SSO Identifier Field Value | A system field used to map the correspondence between users from AD and those from sso |
| API Token | This is the “Barer Token” for access to Deepser’s A.P.I. (Application Programming Interface) To go to the course Deepser’s A.P.I. click here |
| Empowered | Indicates if the user is an Empowered user, Empowered users are end users who are not limited to seeing only tickets for which they are requesters or whose company is the requesting company. |
Once you have filled in the fields, you will need to click on the “Apply” or “Save” button.
After you have created the user you can add it directly in a group by going into the ‘’Groups’’ tab(1) and clicking Add(2).
In the following screen that will open, you will have to check the group(s) that you want the user to be added to(1) and select the action add and then submit it(2).
Then you simply have to close the window and the groups the user is included in will be shown in the “Groups” Tab.
Another way to create a user is directly from an operation(ticket). To do so go to the Service(1) Module and afterwards go inside a ticket.
To create a new user you have to click on the user+ icon at the Requester fieled(2) and a window will pop up. All you have left to do is fill out the necessary fields explained at the table above.
Another case is when the ticket is created with an email, without a user, like this.
All you have to do is click on the user+ icon at the Requester Field and at the window that will pop up, the email field would be automatically filled for you, so you have to complete the rest of the fields.
Note: On user creation, the default role will always be “Users” (in “Role” field), which identifies an end user. Remember to change the role according to your needs. You can check available roles here.
To create a user from the CRM Contacts, you will have to go to the CRM module and then Contact (1). At the page that will open you have to click on the Add Contact Button on the top right of the screen(2).
Then you have to fill out the fields of the Contact Data.
The meaning of the fields is as follows:
| Camp | Description |
| Name | Name of the Contact |
| Surname | Surname of the Contact |
| Salutation | Allows you to Pin the greeting with which Refer to the contact (e.g. Lady or Miss) |
| State | Enable or Disable L Account |
| Department | The Department to which the Contact belongs |
| Qualification | The status of the Contact |
| Manager | Allows Specifying a Contact Manager |
| Source | Indicates the source from which the Lead was generated |
| Rating | Customer Account Satisfaction Level |
| Associate user | Allows Associating Contact to a System User on Deepser |
| Task | Task Related to Contact |
Afterwards you have to complete the information of the user at the Contacts tab and fill out the fields.
The meaning of the fields is as follows:
| Camp | Description |
| Email of the Contact | |
| Telephone | Number of Fixed Telephony |
| Mobile phone | Number of Mobile Telephony |
| Fax | Fax of the Contact |
| Address | Address of the Contact |
| City | City of Contact |
| Province | Province of Contact |
| CAP | Cap of the Contact |
| State | State |
After you have saved the newly created contact, you have to Sync it to a user. You have to go inside the contact and click on ‘Sync User’ on top right of the screen.
In order to change the password any account, you will have to go to
System->Permissions->Users and click on the user’s account you want to change the password to.
Here you can set the new password at the “Password” field (1) and confirm the password at the “Password Confirmation” (2) and simply save the changes (3)
To reset password of an account you will need the email address and the username of the user you want to reset the password. In the login screen you can see at the bottom of the login ‘Forgot your password?’.
By clicking there you will be redirected to the page where you can reset your password.
In this page you should provide username and email address of the account. After you provide the required data click the button ’Recover Password’. If the email address and the username correspond to an user in Deepser a new email should arrive at the email address provided. The email should look like the one given below:
If you click the Reset Password button or link you will be redirected to a new page where you can add your new password.
The criteria for the new password are:
After adding the password and clicking Reset Password button the password will be set to the one you provided and you will be redirected to the login page.
Do you need more informations about of Deepser’s integrated Chat Advanced Configuration? We will explain everything about Public Channel, Chat Widget Integration, etc..
Deepser offers an integrated chat, that allows you to collaborate internally with registered users, or receive requests from external users.
If properly configured, the chat module is accessible in two different ways:
1 – Using widgets, generally at the bottom right.
1b – The chat widget looks like this:
2 – By clicking on the Chat entry in the Deepser backend menu.
2b – This is how the backend chat module shows up:
| Name | Description |
| Channels | Channels where a certain number of users can communicate, possibly organized by topic. |
| Direct | Direct communication between two users. |
3 – To start communicating with a single user, press on the users icon.
4 – Select the user to start the chat with, then press Create Direct Chat.
5 – This is the direct chat section.
The meaning of the elements is the following:
| Element | Meaning |
| Reply Button | It allows users to send normal messages in the chat, which can be viewed by the other participants of the group or by the recipient user. |
| Private Note Button | It allows the creation of a private note within the chat, not visible to other users. |
| Staple icon | It allows sending files as attachments in chat. |
| Emoji Icon | It allows the insertion of an emoji in chat. |
| Send Button | Allows you to send the message. |
1 – Access the system chat configuration, via System->Chat->Configuration
2 – To view the chat widget in the user portal, set “Enabled in Portal” as Yes,to make it available instead in the Guest portal, set Enabled in Frontend as Yes, finally press Save Config
Note: Public Chat Enabled Groups indicates the groups that will be enabled to manage public chat messages.
Max Attachment Size indicates the maximum size of attachments.
3 – To apply the configuration, reboot the Chat Websocket Server.
4 – Once the steps are completed, the chat widget will appear in the portals where it has been enabled.
Deepser chat allows Key User, Agent and Admin to create Rooms .
Channels are spaces where multiple users can communicate, usually about a particular topic.
Let’s proceed with the creation of a channel.
1 – Press the Room creation button
2 – Enter a Name for the Room , and the list of participating users, then press Add room .
3 – Press on the three dots at the top left, then Edit Room.
4 – The channel editing menu will be displayed, with the possibility to add Moderator users.
This table describes the permissions of the room creator, moderators and end users.
| End User | Moderators | Creator | |
| Edit/Delete Room | They cannot create rooms or become moderators, but they can be added to a room . | Both | Both |
| Edit/Delete Messages | Those of which it is sender | Any message | Any message |
| Add/Edit Moderators | No | No | Both |
| Remove the Creator from the Channel | No | No | No |
Note: As can be seen from the table, no one, not even the creator himself, can remove himself from one of his channels.
Deepser’s public chat, is a front-end chat available as a widget in any website or web service, through a script.
This type of communication, allows any unregistered user to send a message, which will then be managed in the Key User, Agent and Admin, if enabled.
Any communication made through the public widget, or in the guest portal, will appear in the Deepser backend, and will be identified by a unique code, representing the cookie released in the machine of the user who sent the message.
On the other left you can see the three statuses of a Public chat:
To assign a chat, click on the icon at the top right, else to just choose to manage the request personally, click below the message.
To mark a conversation as resolved, press the tick button instead.
The user will then see the answer
Deepser’s public chat, is a front-end chat available as a widget in any website or web service, through a script.
This type of communication, allows any unregistered user to send a message, which will then be managed in the Key User, Agent and Admin, if enabled.
Any communication made through the public widget, or in the guest portal, will appear in the Deepser backend, and will be identified by a unique code, representing the cookie released in the machine of the user who sent the message.
Deepser allows a website integration with the frontend chat, thanks to a dynamically generated script based on the parameters entered.
1 – Go to System->Chat ->Widget Configuration, then press ‘Add Widget configuration’.
2 – The widget configuration form will open, fill in the fields with the requested values, then Save.
This is the meaning of the fields:
| Field | Description |
| Name | Sets the name of the widget |
| Domains | Sets the list of domains, from which it is allowed to call the widget, through the script |
| Position | Sets the position where the widget will appear (bottom right/bottom left). |
| Color | Sets the color of the widget. |
| Text | Sets the text that will appear in the bubble icon to open the widget. |
| Website Name | Sets the name of the website that will appear in the widget |
| Welcome Title | Sets the welcome title that will appear once a user opens the widget for the first time. |
| Welcome Tagline | Sets the welcome subtitle that will appear once a user opens the widget for the first time. |
| Can Send Attachments | Allows the user to send files in the chat. |
| Status | The status(Enabled/Disabled) |
| Token | It’s the string that identifies the external implementation of the chat widget, it is automatically set when saved. |
| Widget Script | Field generated dynamically when saving, containing the scripting code, to be inserted to integrate the chat externally. |
3 – Once saved, the token and the Widget Script will appear. This is the script to insert on the site to integrate the chat; copy the code by clicking on the scripting area.
3a– Enable Backend and Frontend to run in frame, in System->Configuration->Admin->Allow Backend to run in frame and Allow Frontend to run in frame
4 – insert the code on the page where you want the support widget to appear.
5 – If the integration was successful, the configured widget will appear at browser cache refresh.
6 – To enable groups to mange public chat messages, go to System->Configuration->Chat->Configurations, then set some groups in Public Chat Enabled Groups.
First of all, to trigger the flow the frontend must be enabled.
You can enable frontend on System -> Configuration.
After it, you must enable the chat on the frontend.
You can enable frontend on System -> Configuration -> Chat -> Configurations
Here, on Configurations -> Enabling, you will have to enable the “Enabled in Frontend” field.
The functionality behind the Bot in Deepser lies behind a flow with a trigger of type chatbot. The Chatbot flow trigger type is executed every time a new chat is created in the frontend area.
2. Configure your bot
Field | Description |
Name | The name of the Bot. |
Flow Heather | The flow to which the Bot is connected. |
Status | Status of Bot. It can be enabled or disabled. |
Avatar | The image of Bot. |
After it, we have to open the template of the chat. We must add to the form the field “Bot”.
This action type is used to directly send a text message on the created chat.
To configure this, you need to open the “Send Message” script. For do this, click “”.
2. Write your message in the field called “Message” and, after it, click “Save”.
This action is used to send a message in the form of a question that waits for a response.
The response can be of type String or Attachment. This response can be used as a variable later on the flow.
To configure this, you need to open the “Ask For Details” script. To do this, click “+”.
2. Write your message in the field called “Message” and after click “Save”.
By using this action, on the chatbot will appear a message in the form of a select field from which the user can select only one answer and cannot type a custom message or add an attachment. The options are mapped through the “value” field which has the role of a key and the “label” field which is the visible option to the user.
To configure this, you need to open the “Ask For Details” script. To do this, click “+”.
2. Write your message in the field called “Message”, insert your options on field “Options” and save clicking the button “Save”.
If you set the field “Add Variable Options” to “ON” you have the opportunity to add an array of options that are retrieved from upper steps of the flow and set to an output variable.
By using this action, the chat is assigned to a specific user present in Deepser who can be an administrator, agent, key user.
With this action, the assigned user can then chat directly with the frontend user.
To configure this, you need to open the “Chat With Operator” script. To do this, click “+”.
On this field is written the text that will be displayed on the chat, informing the frontend user that from now on their request will be assigned to an agent.
This field contains the text message that will be sent to the assigned user.
This field holds a variable of type DeepAdmin- User Model and here is where we assign the user variable retrieved from upper stages of the flow.
On this page we will explain how to set up an example chatbot.
In this example, when a frontend user needs to have some information, the chatbot will assign the chat to the correct backend operator.
For this we will use three different users:
First we will insert the type of trigger as Chatbot
From this block we will get the following variables:
Variable | Description |
Bot | The model of the bot and contains all formtemplate fields. |
Room | This variable represents the chat room. |
All Room Form Fields | This variable contains all formtemplate fields of room model as an array |
In this block we will insert a welcome message into our frontend chat:
When the frontend user starts the chat, the message written in the “Message” field (image above) will be automatically sent to him.
From this block we will not get variables to use later if necessary.
Here, let’s see how to ask the frontend user to enter their first and last name. This information will then be used to rename the room.
The message written in the field will be sent immediately after the welcoming one.
The user will reply to the message from the chat by entering the requested information.This information will be saved in the “Respond” variable.
With this block we will get the following variables:
Variable | Description |
Response | The response entered by the frontend user |
Attachments | The possible attachments inserted |
Attachments Count | Sum of attachments |
With this block we are going to rename the chat room name on the backend side.
N° | Description | Note |
1 | Let’s choose the “Update Record” block. | This way we can change the name of the room |
2 | Let’s choose the chat room as our model. | The response is one of the variables obtained in the trigger (block 1) |
3 | Let’s enter the “Name” field in the query-builder, which will be valorized with the user’s response | The answer is one of the variables derived in block 3 |
Note: This configuration will work when the “Chat with Operator” block is added.
With this block we will get the following variable:
Variable | Description |
(Model) DeepChat – Room | Room template with updated name |
In this block we will see how to insert three options of your choice.
N° | Description | Note |
1 | Let’s choose the “Present Options” block. | In this way we can create the options that will later be shown to the frontend user |
2 | Variables addition | Optional, in this example we take as input the name provided to the user. |
3 | Let’s enter the message that will appear as a header to the options | Here, the text {{var name}} is used to enter the user’s name, entered as input |
4 | Added options that the user will have available to them |
|
The following message will be sent to the user:
Clicking the square of the chosen answer will automatically send the choice as if it had been written by the user
With this block we will get the following variables:
Variable | Description |
Response | The response entered by the frontend user (string) |
Value | Response value |
In this block, we will enter the condition “if option 1 was chosen.”
N° | Description | Note |
1 | Let’s choose the “If” block. |
|
2 | Let’s set the desired condition | In this case we set user-chosen value is “support incident/request” |
Entry into this block will only occur if the frontend user chooses “support incident/request”(1) as an option.
Here, we will retrieve the “Support” user, who will be the operator to whom the chat will be sent.
N° | Description | Note |
1 | Let’s choose the “Lookup Record” block. | This will allow us to retrieve the user “Support” |
2 | Let’s choose the model “DeepAdmin – User” |
|
3 | As a filter let’s enter the “user_id” | In this example, the user “Support” has id 53 |
With this block, we will get the following variables:
Variable | Description |
(Model)DeepAdmin – User | Model with user data |
Model Alias | For this model it will be “deep_admin/user” |
This block will handle the handover of the chat to the “Support” operator.
N° | Description | Note |
1 | Let’s choose the block “Chat with operator” |
|
2 | Field in which a message can be inserted for the frontend user | Optional |
3 | Field in which you can enter a message for the operator | Optional |
4 | The user retrieved in block 6 is inserted from the variables | Optional, if left blank it will be sent to all enabled users. |
In this block, we will insert the condition “if option 2 was chosen.”
N° | Description | Note |
1 | Let’s choose the “else If” block. |
|
2 | Let’s set the desired condition | In this case, the value chosen by the user is “sales problem/request” |
Entry into this block will occur only if the frontend user chooses “sales problem/request”(2) as an option. Here, we will retrieve the user “Sales,” which will be the operator to whom the chat will be sent.
N° | Description | Note |
1 | Let’s choose the “Lookup Record” block. | This will allow us to retrieve the user “Sales” |
2 | Let’s choose the model “DeepAdmin – User” |
|
3 | As a filter we enter the user_id | In this example, the user “Support” has id 54 |
With this block, we will get the following variables:
Variable | Description |
(Model)DeepAdmin – User | Model with user data |
Model Alias | For this model it will be “deep_admin/user” |
This block will handle the handover of the chat to the “Sales” operator.
N° | Description | Note |
1 | Let’s choose the block “Chat with operator” |
|
2 | Field in which a message can be entered for the frontend user | Optional |
3 | Field in which you can enter a message addressed to the operator | Optional |
4 | The user retrieved in block 9 is inserted from the variables | Optional, if left blank it will be sent to all enabled users. |
In this block, we will insert the condition “if option 3 was chosen.”
N° | Description | Note |
1 | Let’s choose the “else If” block. |
|
2 | Let’s set the desired condition | In this case, the value chosen by the user is “administration incident/request” |
Entry into this block will occur only if the frontend user chooses “administration incident/request”(3) as an option.
Here, we will retrieve the “Administration” user, which will be the operator to whom the chat will be sent.
N° | Description | Note |
1 | Let’s choose the “Lookup Record” block. | This will allow us to retrieve the user “Administration” |
2 | Let’s choose the template “DeepAdmin – User” |
|
3 | As a filter we insert the user_id | In this example, the user “Support” has id 55 |
With this block, we will get the following variables:
Variable | Description |
(Model)DeepAdmin – User | Model with user data |
Model Alias | For this model it will be “deep_admin/user” |
This block will handle the handover of the chat to the operator.
N° | Description | Note |
1 | Let’s choose the block “Chat with operator” |
|
2 | Field in which a message can be entered for the frontend user | Optional |
3 | Field in which you can enter a message for the operator | Optional |
4 | The user retrieved in block 12 is inserted from the variables | Optional, if left blank it will be sent to all enabled users. |
The cmdb in Deepser is a database made available to the user.
It is the tool used to create records (Custom item or CI) and store the information, organised by a Type, a Subtype and a Class.
In this course we will deal with the CMDB in all its parts.
The CMDB in Deepser is a database made available to the user.
It allows you to create records (Configuration item or CI), each of them characterized by a Type, a Sub Type and a Class.
Classes make it possible to distinguish ci into macro categories.
The defined macro categories will be displayed on the backend side inside the CMDB menu as shown in the figure below.
Types allow you to add a type layer to the elements defined in the classes.
On one hand, it allows you a more granular management of visibility permissions.
On the other hand, it allows us to make it more immediate to understand what that particular refers to.
Subtypes allow you to add a type layer to the elements defined in the Types.
This allows on the one hand a more granular management of visibility permissions; on the other hand, it allows us to make it more immediate to understand what that particular refers to.
As mentioned above, there are similar to records in a database that allow you to create custom entities within Deepser.
These entities can be assigned to users who will be able to view and edit these entities.
An example of use is for example the management of the devices assigned to the users, in this case once assigned the ci to the user, it will be able to display any information concerning the device itself for example serial number, any pins or associated codes or any other kind of information that may be useful to manage for the assignee user.
Types allow you to add a type layer to the elements defined in the classes.
This allows on the one hand a more granular management of visibility permissions; on the other hand, it allows us to make it more immediate to understand what that particular refers to.
To enable the cmdb in the user portal you will need to go to the menu: System->Configuration.
Here it will be a must to go to the “Portal” item.
At this point, the following screen will open:
You will need to set the “Enable” field to “Yes”, this will enable the CMDB for the user portal.
The default “Enabled Priority” field on “Global” allows you to specify whether the CMDB will be enabled for all users (default) or if set to “User” it will be enabled only for users for whom the Portal CMDB Visibility field has been set to “Yes”.
To configure the CMDB grid in the user portal, you will need to go to the menu: System->Portal->Ci.
Here you can configure the grid using the pencil button at the top left.
Once you click the pencil button, both will open the following screen:
Here, you can insert new fields in the grid by dragging them from the “Available Columns” column to the “Visible Columns” column.
As per the image below.
In addition, from here it will be possible to modify what will be visible through the configuration of the query builder, in the example below we want to make visible only those that belong to the “Locations” class.
Note that these configurations will apply to all end users, to make a more granular configuration it will be possible to implement a custom script, as we will see in the next lessons.
In Deepser you can define a custom script that allows you to specify advanced conditions for the collection of us to be displayed.
In this case we suppose we want to make visible only to some End-users all the categories of the CMDB, all the others we want to display only on the CI of class 1 (Location).
To do this, we must go to the menu: System -> Portal -> CI.
Here, we will have to click on the pencil-shaped button.
Now the following screen will open:
In the “Prepared Collection Script” section, we are going to insert the following code:
//Array of technicians, who can see all the cis
$technicians = ['deepser_tec','mario.rossi'];
//if the current user is not in the technicians array he or she colud only see cis with class_id 1
if((!is_null($technicians) && is_array($technicians)) && (!(in_array(Deep::helper('deep_admin')->getCurrentUser()->getUsername(),$technicians)))){
$this->getCollection()->addFieldToFilter('class_id', [ "eq" => 1 ]);
}
Note: that the array technicians contain the usernames of the users and not the Display usernames.
Once this is done, you will need to click on the “Save” button to save the changes.
In this case we suppose we want to make visible only to some End-users all the categories of the CMDB, all the others we want to have visibility only on the class 1 CI (Location), compared to the previous case in this case we are going to define a custom field of checkbox type that will allow you to define in a simpler way which users will be able to view all the ci.
To create the custom field, we must go to the menu: System -> Custom Fields
Here we will have to go in user model.
At this point in the “Fields” section, we are going to click on the “Add Field” button.
Now the following screen will open:
Here we are going to define the “Code” field as “is_cmdb_technician”.
The “Label” field will instead be “Is Technicians”.
Now, we configure “Column type” as “Integer”.
At this point, we define the “Element Type” field as “Checkbox”.
As a last step, going to the “extra” tab we set the flag: “Render as Toggle” to “Yes”.
At the end, click on the “Save” button to save the custom field.
At this point, it will be necessary to insert the newly created field in the users’ template form, and we will enhance it for those users who will have to see all the CI.
Now to implement the actual filter, we must go to the menu: System -> Portal -> CI.
Here, we will have to click on the pencil-shaped button.
Now the following screen will open:
In the “Prepared Collection Script” section, we are going to insert the following code:
$userArray = Deep::getResourceModel('deep_admin/user_collection')->addFieldToFilter('cust_is_cmdb_technician',[ ["neq" => 1], ['null' => true]]);
$userlist = [];
foreach($userArray as $user){
$userlist[$user->getUsername()] = $user->getDisplayUsername();
}
if(( !is_null($userlist) && is_array($userlist)) && (array_key_exists(Deep::helper('deep_admin')->getCurrentUser()->getUsername(),$userlist))){
$this->getCollection()->addFieldToFilter('class_id',["eq" =>1]);
}
Once this is done, you will need to click on the “Save” button to save the changes.
In Deepser Cis Class, Type and SubType are organized in hierarchical ways starting from the highest level of the hierarchy we have the classes; each class can then be associated with one or more Types and at the end of each Type will be associated one or more SubTypes.
In this guide we will see how to configure the hierarchy of classes, Type and SubType.
To configure a new class, you will need to go to the System -> CMDB Configuration-> Class menu.
Here, you will need to click on the “Add Class” button.
At this point, the following screen will open:
Below is a table with the name of the fields and their meaning:
| Field | Description |
| Name | The name of the class. |
| Status | The Status of the class, if “Enabled” the class will be displayed otherwise it will be neither viewable nor setable and with it will also be hidden the ci of that class. |
| Enabled Groups | Groups that can see that class and interact with the |
| Icon | Class icon, it is used to make it easier to recognize the class at first glance. |
| Position | Position of the class, this field will allow you to define the order in which the classi will be displayed in the sidebar. |
Once you have filled in the fields in the desired way, you can click on the “Save” or “Apply” button to save the class
To configure a new Type, you will need to go to the System -> CMDB Configuration-> Type menu.
Here, you will need to click on the “Add Type” button.
At this point, the following screen will open:
Below is a table with the name of the fields and their meaning:
| Field | Description |
| Class | The class to which the Type belongs. |
| Name | The Name of the Type. |
| Status | The Status of the Type, if “Enabled” the Type will be displayed Otherwise essor will not be viewable or settable. |
| Icon | Class icon, it serves to make it easier to recognize the Type at first glance. |
| Position | Location of the Type, this field will allow you to define the order in which the Types will be displayed. |
Once you have filled in the fields in the desired way, you can click on the “Save” or “Apply” button to save the type.
To configure a new Subtype, you will need to go to the System -> CMDB Configuration->SubType menu.
Here you will need to click on the “Add SubType” button.
At this point, the following screen will open:
Below is a table with the name of the fields and their meaning:
| Field | Description |
| Type | The Type to which this Subtype will be associated. |
| Name | The Name of subtype. |
| Status | The Status of the Subtype, if “Enabled” the Subtype will be displayed Otherwise essor will not be viewable or settable |
| Icon | Subtype icon, it is used to make it easier to recognize the Subtype at first glance. |
| Position | Location of the Subtype, this field will allow you to define the order in which the Subtypes will be displayed in the sidebar. |
Once you have filled in the fields in the desired way you can click on the “Save” or “Apply” button to save the Subtype.
To create a new CI in Deepser you will need to go to the menu: CMDB-> All.
Here you can click on the “Add Us” button.
Now in the window that will open you will need to choose the type of us to create and then click on the “New” button.
At this point, the following screen will open:
Below is the name of the fields and their meaning:
| Name | Meaning |
| Name | Name that will be associated with the new CI. |
| Category | The category associated with what you are creating. |
| Class | The class of CI. |
| Type | The Type of the |
| Subtype | The SubType of the CI. |
| Description | Description Del CI. |
| Serial Number | Serial Number of the CI. |
| Front Image | Front image of the CI. |
| Business Impact | Impact on the business of the CI in question. This field indicates how important this is to the company’s business. |
| Priority | Priority of the CI. |
| Urgency | Urgency of the CI. |
| Notes | Notes Associated with this there. |
In the “User Details” tab, there will be the following fields:
Below is the name of the fields and their meaning:
| Name | Description |
| Owner Company | Company that owns the company |
| Owner Group | Group owner of the CI |
| Owner User | User owner of the CI. |
| Assigned Company | Company assigned to us |
| Assigned Group | Assignee group of the CI |
| Assigned User | User assignee of the CI. |
| Updated By | The last user who updated the CI, at the beginning will be the user who created the CI. |
In the “Activity/Attachments” tab, there will be the following fields:
Below is the name of the fields and their meaning:
| Name | Description |
| Task | Tasks Associated with CI. Before we can enter tasks associated with this, we will need to save it at least once. |
| Activities | Activities associated with the CI, could be comments or worklogs associated for example with the maintenance of the CI. |
| Attachments | Attachments of the CI, this field can be used to upload files that regarding a CI. |
In the “Relations” tab there will be the following fields:
Below is the name of the fields and their meaning:
| Name | Description |
| Relation to Other CIs | This field will show relationships with others there (when present) |
In the “History” tab, there will be the following fields:
| Name | Description |
| History Changes | This field will contain the list of changes made to this field so that you know who made changes on it. |
Once you have filled in the fields, you can click on the “Save” button to save the CI just valued.
In Deepser it is possible to implement a user registration procedure to allow new users to register independently among the users present in Deepser.
Below, we will cover the procedure necessary to implement the creation of a registration form in Deepser.
Deepser allows you to create a registration form by combining one or more Step components.
To create a “Step” you will need to go to the “System -> Permissions -> user Registration -> Step” menu
In the screen that will open, you will need to click on the “Add Step” button.
Once you click the button, you will be redirected to the creation screen of a new step.
Below we briefly report the meaning of each field:
| Field | Description |
| Name | Step name |
| Position | Position in the step grid. |
| Label | Written that will appear to users when the step is uploaded. |
| Is Default step | Indicate if this is the step from which the recording will begin |
| Is Final step | Indicate if this is the step that will end the recording |
| Next step | Next step in the registration, null if the current step is the step that will end the registration |
| Check Token | Checks whether the verification token is present in the request. |
| Send Token | Submit the verification token |
| Token Duration | Token duration in hours and minutes |
| Mailbox | Indicates the mailbox with which the messages will be sent to the user during registration |
| Email Event | Email event associated with registration (if any) |
| StepData Formtemplate | Form template associated with the current step |
| Validate Expression | Custom code that allows you to validate the input data |
| Final Message | Final message that will be displayed by the user if the current step is set as the final step |
| Create User | Indicates whether a user will be created in this step |
| Create Active User | Indicates whether an active user will be created in this step |
| Send Reset Password | Indicates whether a password reset email will be sent to the user |
| Field Config | Mapping user principal fields to form template fields |
| User Create Expression | Custom code that will be used to create a user |
| Status | Indicates whether this step is active or not. |
In the successive lessons we will cover the creation of a registration form that allows a user to register himself and access the support, but only to users who belong to a company registered in Deepser, this to prevent external users from opening tickets without permission.
Before proceeding with the actual creation of the form, we must create a custom field that allows us to receive user input.
In the following example, we will see how to create a user only if the VAT number entered will correspond to one of the companies present in Deepser. For this example, we will assume that there is a custom field named “cust_vat_number” that will contain the VAT number of the company.
The Custom Fields will be addressed in another lesson, to go to the lesson related to the Custom Fields click here.
To create a custom field, we must go to: System -> Custom Fields.
Here we will have to click on the model “DeepRegistration – stepData”.
On the next screen, we will have to click on the “Add Field” button.
In the screen that will be displayed, will need to fill in the fields as follows:
Important is to set the “Column Type” and “Element Type” fields to text.
At this point, you will need to click on the “Save” button
Once this is done, we can proceed to implement the registration form.
In order to create the Registration Form we must go to the step creation menu to create a new step.
The Step Section is located under the “System-> Permissions – > user Registration -> Step” menu.
At this point, we give a name to our registration form by entering the desired name in the “Name” field
We define the “Position” field as zero.
Now we set the label that will be displayed on the registration screen by entering the desired text in the “Label” field.
Note that this field can contain text or even html with its css styles.
We define “Is Default Step” field to yes, in this way we are defining what will be the step from which the registration will begin.
Since in our example we have only one registration step, we also define “Is Final Step” to “Yes”.
Since in our example we have only one registration step we define “Next Step” as none, in the case of a multistep registration it will be possible to set what will be the next step, through this field.
Another important thing to notice is that to populate the field, you will first need to create a new step.
We set what will be the email box that we will use to send any Password change emails through the “Mailbox” field
Now we set which form template we want to display during registration using the field “StepData Formtemplate”
In the “Validate Expression” field, we can go to define the custom code that we will need to carry out checks on the validity of the data passed in input.
Within this field we are going to enter the following code:
/**Defining Variables**/
//Assigning StepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value og the cust_vat_number field to a variable.
$vatNumber = $stepData->getData('cust_vat_number');
//Assigning the value of the email field to a variable.
$email = $stepData->getData('email');
//if the email isn't in a valid format return an error to the user.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$this->addError("Email is not in a valid format");
}
//Retriving form the user collection all the users the have the username equivalent to the ginven e-mail.
$usersCollection = Deep::getResourceModel("deep_admin/user_collection")->addFieldToFilter("username",["eq" => $email]);
//Retriving form the user collection all the StepData the have the username equivalent to the ginven e-mail.
$stepDataCollection = Deep::getResourceModel("deep_userregistration/stepdata_collection")->addFieldToFilter("email",["eq" => $email]);
//If uone or more user or StepDatas where found retun an error to the user.
if($usersCollection->count() || $stepDataCollection->count()){
$this->addError("Email Already Registered");
}
/**If the company is present in Deepser we allow the registration otherwise throw an error**/
//Loading a company ginven the cust_piva field, if there is non company with this field this method retrive a new object.
$company = Deep::getModel("deep_company/company")->load($vatNumber,'cust_piva');
//If the returned object doesen't have the id or is null,return a error to the user.
if(!($company && $company->getId())){
$this->addError("We are sorry, but only employee of our customer can register an account");
}
In the field “Final Message” we will define the message that we will give to the user once the registration has been successfully completed.
Here, we will insert the following code:
<style>
.cust__msg{
margin-left: auto;
margin-right: auto;
display: flex;
flex-direction: column;
}
.cust__msg > *{
text-align: center;
box-sizing: border-box;
margin-left: auto;
margin-right:auto;
width: 100%;
}
.cust__msg .row{
display: flex;
justify-content:space-evenly;
padding-right: 30%;
padding-left: 30%;
}
</style>
<div class="cust__msg">
<h1>Success</h1>
<p>Congratulations, your account has been created!.</p>
<div class="row">
<div class="col-sm-3">
Username:
</div>
<div class="col-sm-3">
<?php echo $this->getStepdata()->getData('email');?>
</div>
</div>
<div>
<h6>We have sent you an email with the link to reset your password.</h6>
</div>
</div>
At this point, we will have to define to create a user by defining the field “Create User” to”Yes”.
Now, we will define if the user will be an active user by defining the field “Create Active User” to “Yes”
Now we will define whether to send the user an email at the end of the procedure that will allow him to reset the password using the “Send Reset Password” field.
Now, in the “Field Config” field we will define the mapping of the user template fields with the form fields. To add a new field to map with the form data simply click the “+” button.
We have defined the users’ field as follows:
In the “User Create Expression” field, we can define custom code that will allow us to set the user’s attributes or in general to perform actions when creating a new user.
In this field, we will enter the following code:
//getting the datas from the form
$stepData = $this->getStepdata();
// assigning the end user role to the created user by passing the role id
$this->getUser()->setData("role",73);
Finally, we set the “Status” field to Enabled (If it wasn’t already set to Active).
At this point, you will need to click on the button “Save” or “Apply”
To modify the form template that will be displayed during registration, you will need to click the “Preview” button
At this point, you will need to click the pencil button:
And then go to the StepData tab:
Here you can enter the fields by dragging them from the right column into the grid
Finally, you will need to click on the Save Button.
During the registration phase it may be necessary to validate the user’s email, to do this you can send a token that will allow you to verify the user’s email.
Taking as a basis the previous example, we create another step, this time ignoring the part related to the creation of the account, in addition we will configure the sending of the token.
In order to send the verification token to the end user it will be necessary to create an email event with its associated template form that will be used by Deepser to send the email to the user who is registering.
To create a custom mail event you will need to go to the System -> Tools -> Email -> Templatemenu.
Then you will need to click on the “Add MailTemplate” button.
In the screen that will open you will need to define a name for the template, to do this, simply enter the desired name in the “Name” field.
Next, we will define a code for the template, filling in the “Code” field.
At this point, it will be possible to insert in the “Subject” section the php code that will compose the subject of the email.
You can use the following code as a reference to compose the subject of the email:
<?php echo Deep::helper('deep_email')->__('DEEPSER - Confirm your Registration')?>
Now it will be possible to insert in the section “Body”, that will represent the content of the message, the PHP / HTML code that will serve to generate the body of the mail.
You can use the following code as a reference when creating the body:
<?php
$username = $this->getModel()->getEmail();
$firstname = trim($this->getModel()->getFirstname());
$lastname = trim($this->getModel()->getLastname());
$tmpFullname = $firstname . $lastname;
$fullname = $fullanme != "" ? $tmpFullname : "user";
$url = $this->getModel()->getTokenStepUrl();
?>
<?php $this->includeTemplate("header") ?>
<!-- Start of Main Content -->
<tr style="">
<td bgcolor="#FFFFFF" align="center" style="">
<table width="100%" align="center" cellpadding="0" cellspacing="0" border="0" class="devicewidth" style="">
<tbody style="">
<!-- Start Spacer -->
<tr>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td class="h26" height="36" style="font-size:1px; line-height:1px;"> </td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
</tr>
<!-- End Spacer -->
<tr style="">
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td class="mktEditable content mktEditable content" id="edit_text_1" valign="middle" style="font-family:Calibri, Helvetica, sans-serif; font-size:16px; color:#505050; text-align:left; line-height:25.6px; font-weight:normal; text-transform:none;">
<p>
<br>
<?php echo Deep::helper('deep_email')->__('Dear %s',$fullname);?>,<br>
<?php echo Deep::helper('deep_email')->__('Please confirm your registration by clicking the link below'); ;?><br>
</p>
</td>
</tr>
<!-- Start Spacer -->
<tr>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td height="30" style="font-size:1px; line-height:1px;"> </td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
</tr>
<!-- End Spacer -->
</tbody>
</table>
</td>
</tr>
<!-- End of Main Content -->
<!-- start of Button -->
<tr style="">
<td bgcolor="#FFFFFF" align="center" class="mktEditable" id="edit_cta_button" style="">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td class="w22" width="41" style="font-size: 1px; line-height: 1px;"> </td>
<td align="left">
<table class="button" cellpadding="0" cellspacing="0" border="0" align="left" bgcolor="#0080ff" style="-webkit-border-radius: 4px; -moz-border-radius: 4px; border-radius: 4px;">
<tbody>
<tr>
<td width="518" align="center" valign="middle" height="65">
<span style="color: #ffffff; text-decoration: none;">
<a class="mobButton mktNoTok" href="<?php echo $url ?>" style="font-family: Calibri, Helvetica, sans-serif; font-size: 16px; color: #ffffff; display: block; height: 65px; mso-line-height-rule: exactly; line-height: 65px; font-weight: normal; text-decoration: none; text-align: center!important;" target="_blank" title="Link al ticket">
<?php echo Deep::helper('deep_email')->__('Confirm the registration')?>
</a>
</span>
</td>
</tr>
</tbody>
</table> </td>
<td class="w22" width="41" style="font-size: 1px; line-height: 1px;"> </td>
</tr>
</tbody>
</table>
</td>
</tr>
<!-- end of Button -->
<?php $this->includeTemplate("footer") ?>
And click on the “Save” or “Apply” button:
To create a custom mail event, you will need to go to the “System -> Tools -> Email -> Event” menu.
At this point, you will need to click on the “Add Event” button.
The following page will be displayed:
At this point, it will be necessary to give a name to the event by filling in the “Name” field.
We define Whether to send attachments, changing the value of the field “Send Attachments”, in our case we set it to “No”.
Now, in the “Email Template” field, we select the template created in the previous point of this guide.
In the “Event Trigger”section, select “DeepUserregistration-StepData” in the “Model” field
In the “Event Expression” entry.
We insert the following code :
return true;
In the “To” section
We insert the following code :
/**Configuring the language with local **/
$this->changeLanguage($this->getModel()->getCustLocale());
/**Getting the email from the current model**/
$this->addTo($this->getModel()->getEmail());
At this point, we can go to click the “Save” or “Apply” button
Now the event will have been saved.
To create a new form template, you will need to click on “Preview”.
Here, you will need to click on the button with the arrow icon.
Now you will need to click on “New Formtemplate”
In the screen that will open, you will need to enter in the field “Enter Template Name” the name of the new form template.
Next, you will need to click on “Save”.
At this point, the new form template will be created.
To create a new form template, you will need to click on “Preview”.
Here you will need to click on the button with the pencil icon.
Here you will need to go to the “Fieldset”: “Step data”.
At this point it will be necessary to locate the field that we want to make mandatory and click on the corresponding gear icon.
In the screen that will open you will need to change the field “Required” and set it to “Yes”.
Now you will need to click on the “OK” button on the field configuration screen.
Finally, you will need to click on the “Save” button in the form configuration window.
At this point the field will be mandatory.
Deepser evaluates form templates from the highest priority to the lowest priority form templates.
The priority of the form templates is therefore important to define which form template the user will see.
To set the priority, you will need to go to the arrow key.
Now click on the template you want to edit.
At this point, click on the button with pencil icon.
Now you will need to click on the “Edit Rules” button and then subsequently set a value in the priority field.
Finally, click on the “Save” button.
For this example we will use as a basis the step created in the previous lessons, in addition we will create two form template the first named “First” with the email fields, Firstname and Lastname and the second named “Second” with only the Vat Number field (cust_vat_number) created in the previous points of lessons of this guide.
Let’s go to the Step section and click on the “Add Step” button
In this new we are going to configure the field “Name”, in this field we will enter the name we want to give to the step.
We configure the field “Position” to 0
We configure the field The “Label”, this field will contain the inscription that the user will see when he arrives at this form.
We configure the field “Is Default Step” to “Yes”.
We configure the field “Is Final Step” to “Yes”.
We configure the “Next Step” field on the step created in the previous points (User Support Registration).
We configure the field “Check token” to “No”.
We configure the field “Send Token” to “Yes”.
We set the “Token Duration”field, to an hour or at least to the time that we believe to be sufficient to perform the registration.
We configure the”Mailbox”fieldwith the exit mailbox that we will use for registraction.
We configure the “Email Event”fieldwith the mail event created in the point above.
At this point we set the field”StepData Formtemplate” form template that we want to use in this first step, in the template form we set all the fields that must be filled in as mandatory, in this way the user will have to fill them in order to continue, you can refer to the previous topic for the configuration of the form field as mandatory click here to go to the guide.
To create a custom form template you can follow the guide found in the previous article, click here to go to the guide.
We can configure the fields “Create User” and “Create Active User” to “No”.
In the “Validate Expression” field, we insert the following code to verify the form template.
/**Variables Initialization**/
//Assigning the stepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value of the email field to a variable.
$email = $stepData->getData('email');
/**Verifications**/
//if the emil isn't in a valid format return an error to the user.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$this->addError("Email is not in a valid format");
}
//Retriving form the user collection all the users the have the username equiva-lent to the ginven e-mail.
$usersCollection = Deep::getResourceModel("deep_admin/user_collection")->addFieldToFilter("username",["eq" => $email]);
//Retriving form the user collection all the StepData the have the username equivalent to the ginven e-mail.
$stepDataCollection = Deep::getResourceModel("deep_userregistration/stepdata_collection")->addFieldToFilter("email",["eq" => $email]);
//If uone or more user or StepDatas where found retun an error to the user.
if($usersCollection->count() || $stepDataCollection->count()){
$this->addError("Email Already Registered");
}
In this case we can leave the field “Field Config” as we are going to manage the creation of users in the last step
We can leave the”User Create Expression”field blank because we will not create users in this step.
At this point, Click on the Apply or Save button.
In the end, the step will be saved.
Let’s move now on to the final registration step.
In this step, we are going to change the”Check Token”field by setting it to “Yes”.
And we will configure the form template that will be associated with this template using the field “StepData Formtemplate”.
At this point, we modify the Form Validate Expression field to perform the only validation of the “Vat Number” (in the case of example).
**Defining Variables**/
//Assigning StepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value og the cust_vat_number field to a variable.
$vatNumber = $stepData->getData('cust_vat_number');
/**If the company is present in Deepser we allow the registration otherwise throw an error**/
//Loading a company ginven the cust_piva field, if there is non company with this field this method retrive a new object.
$company = Deep::getModel("deep_company/company")->load($vatNumber,'cust_piva');
//If the returned object doesen't have the id or is null,return a error to the user.
if(!($company && $company->getId())){
$this->addError("We are sorry, but only employee of our customer can register an account");
}
Note: this form template must have a higher priority than all the others
At this point, you will need to click on the “Save” or “Apply” button.
To enable the possibility of registering through the registration form, it will be necessary to go to the System -> Configurations -> Admin -> Security menu.
Here you will need to change the field “Enable User Registration” and set it to “Yes”.
Now, to save the changes, you will need to click on the “Save Config”button.
At this point, the registration link will have appeared on the main Login page:
This Course will give you a better knowledge on how Rights, Permissions and General Visibility Works in every Deepser’s Module. We will talk about Users, Groups, Roles and Companies from the System Admin Perspective.
In Deepser the resources are basically the modules or service that Deepser makes available.
An example of the exposed resources is shown below.
The visibility of the resources in Deepser can be set up to the model level.
The user will only be able to see modules and resources that have been set as visible to the membership role.
In Deepser, roles are used to define which resources the user will have access to.
We can exemplify the concept roles manage Vertical visibility in Deepser, that is, the visibility of the modules presents in the sidebar
The default roles in Deepser are:
| Role | Description |
| Admininstrator | Administrators Users in Deepser, are users that have global access and bypass the limits of visibility in the backend, in addition to them have faculty to modify the grids and form templates. This is the only role that has access to the system configurations and the System tab. |
| Super Admin | Super Admins are users with Administrator role who have set “All” in the resource visibility section. This role is the only one that has access to scripting areas. |
| Agents | These Users have the right to modify the grids and form templates, but they do not have access to the scripting areas or even to the modules placed in the System tab. For the rest by default, they have global access to all other modules. |
| Key Users | These users are comparable to Agents users, but unlike the latter they have no ability to modify any system configuration, including grids and form templates. |
| Users | These are the end users, as a rule, these users do not have access to the backend but only to the end user portal. Since they do not have access to the backend, they cannot change any system configuration or even see the tickets that have not been opened by them. If there is a need for an end user to see tickets not opened by himself, he can be modified by setting him as a Company Supervisor, in this case the user will be able to see all the tickets created by his company. Alternatively, you can configure the user as empowered user, this will give him visibility even on tickets not belonging to his company. |
In deepser, roles are an important component in visibility management.
The roles allow you to manage the visibility of the modules accessible to user accounts (e.g. password, crm etc) or even which users can access the Deepser backend and which can only access the user portal.
To create a role in Deepser you will have to go to the “System the Permissions->Roles” menu.
At this point in the screen that will open you will have to click on the “Add New Role”
On the next screen you can set the “Role Name” field which will define the name that will have the new role.
In the type field it will be possible to define the Type that will have this role by compiling the “Type” field.
Then moving to the “Roles Resources” tab you can define which resources will be visible to the user to whom this role will be assigned by configuring the “Resource Access” field to Custom an selecting the resources you want to expose to this role.
Note: if you want to set the role to have no visibility limitations you can opt to select from the drop-down menu the item “ALL” instead of the item “Custom”, in this way no visibility limitations will be applied on the role (however this will not affect the visibility configured for groups).
Now click on the “Apply” or on the “Save” button.
Once the role has been created, a third item will appear in the list of tabs: Role Users.
Using this tab you can get a quick overview of all the users who have been assigned that role.
A user in Deepser is an individual who interacts with the system, utilizing its features and functionalities.
To create a new user in Deepser you will need to go to the menu System -> Permissions -> Users(1)
In the screen that will open, you will need to click on the “Add User” button(2)
At this point, the following screen will open:
| Field | Description |
| Avatar | Profile picture of the user. |
| Username | Username of the user, this will serve to log in, this is a mandatory field to create and in addition this field must be unique within Deepser. |
| Firstname | The name of the user. This is a required field |
| Lastname | User’s lastname. |
| User’s email | |
| Password | Password of the user, note that this field is always white because the user’s password is not stored in a database format that is invertible, consequently the field remains unvalued by default even if the user has a password set, except when changing the password itself. In case of changes to this field when saving the user Deepser will automatically update the value of the password present in db. |
| Password Confirmation | Confirm the user’s password, like the previous field, this is also not valued except when changing the password itself. |
| Role | The role of the user, depending on the role the user will have different visibilities on the various parts of the product. For example the Users role, who by default sees only the End User Portal. The roles of the users will be deepened in the dedicated Lesson, click here to go to the corresponding lesson. |
| Active | Indicates whether the user is authorized to access Deepser. If the value is “Active” the user will be enabled to access, if the value is “Inactive” then the user will not be authorized to access Deepser. |
| Startup Page | This field indicates which is the default page to which the user will be redirected after logging in. |
| Local | Indicates the language in which the user visualizes Deepser interface |
| Timezone | It indicates the time zone associated with that user, it is important to indicate the correct time zone so that Deepser can correctly set the format of the dates in notifications and date fields. |
| Company | The company field indicates which company the user belongs to, this field is very important since Deepser companies are one of the key elements in visibility management. The companies will be analyzed in the following lessons, click here to go to the lesson on the companies. |
| Additional Companies | Additional companies indicate to the data of which other companies the user will have access. This topic will be deepened in the lesson on company, this field will be selectable only after the user has been saved at least once |
| Is Supervisor | This field indicates whether the user will be a company supervisor. A company supervisor will have the ability to view and modify the tickets created by the users of his company |
| Company Visibility | This field indicates if the user will have limited visibility to Company Data |
| Portal CMDB Visibility | This field indicates if the user will see the cmdb in the user portal. |
| OTL Token | This token if passed as a parameter (token) in the url of the request (query string) allows you to access Deepser without logging in. Note that the setting of direct access by token is by default disabled for security reasons, in addition for security reasons this token has validity of only one use, after which it is automatically reset by the system, this is done to avoid data theft. |
| rp_token | This token is used to reset a user’s login credentials. This is a system field, at the operational level there is no use for this field. |
| LDAP SSO Identifier Field Value | A system field used to map the correspondence between users from AD and those from sso |
| API Token | This is the “Barer Token” for access to Deepser’s A.P.I. (Application Programming Interface) To go to the course Deepser’s A.P.I. click here |
| Empowered | Indicates if the user is an Empowered user, Empowered users are end users who are not limited to seeing only tickets for which they are requesters or whose company is the requesting company. |
Once you have filled in the fields, you will need to click on the “Apply” or “Save” button.
After you have created the user you can add it directly in a group by going into the ‘’Groups’’ tab(1) and clicking Add(2).
In the following screen that will open, you will have to check the group(s) that you want the user to be added to(1) and select the action add and then submit it(2).
Then you simply have to close the window and the groups the user is included in will be shown in the “Groups” Tab.
Another way to create a user is directly from an operation(ticket). To do so go to the Service(1) Module and afterwards go inside a ticket.
To create a new user you have to click on the user+ icon at the Requester fieled(2) and a window will pop up. All you have left to do is fill out the necessary fields explained at the table above.
Another case is when the ticket is created with an email, without a user, like this.
All you have to do is click on the user+ icon at the Requester Field and at the window that will pop up, the email field would be automatically filled for you, so you have to complete the rest of the fields.
Note: On user creation, the default role will always be “Users” (in “Role” field), which identifies an end user. Remember to change the role according to your needs. You can check available roles here.
To create a user from the CRM Contacts, you will have to go to the CRM module and then Contact (1). At the page that will open you have to click on the Add Contact Button on the top right of the screen(2).
Then you have to fill out the fields of the Contact Data.
The meaning of the fields is as follows:
| Camp | Description |
| Name | Name of the Contact |
| Surname | Surname of the Contact |
| Salutation | Allows you to Pin the greeting with which Refer to the contact (e.g. Lady or Miss) |
| State | Enable or Disable L Account |
| Department | The Department to which the Contact belongs |
| Qualification | The status of the Contact |
| Manager | Allows Specifying a Contact Manager |
| Source | Indicates the source from which the Lead was generated |
| Rating | Customer Account Satisfaction Level |
| Associate user | Allows Associating Contact to a System User on Deepser |
| Task | Task Related to Contact |
Afterwards you have to complete the information of the user at the Contacts tab and fill out the fields.
The meaning of the fields is as follows:
| Camp | Description |
| Email of the Contact | |
| Telephone | Number of Fixed Telephony |
| Mobile phone | Number of Mobile Telephony |
| Fax | Fax of the Contact |
| Address | Address of the Contact |
| City | City of Contact |
| Province | Province of Contact |
| CAP | Cap of the Contact |
| State | State |
After you have saved the newly created contact, you have to Sync it to a user. You have to go inside the contact and click on ‘Sync User’ on top right of the screen.
In order to change the password any account, you will have to go to
System->Permissions->Users and click on the user’s account you want to change the password to.
Here you can set the new password at the “Password” field (1) and confirm the password at the “Password Confirmation” (2) and simply save the changes (3)
To reset password of an account you will need the email address and the username of the user you want to reset the password. In the login screen you can see at the bottom of the login ‘Forgot your password?’.
By clicking there you will be redirected to the page where you can reset your password.
In this page you should provide username and email address of the account. After you provide the required data click the button ’Recover Password’. If the email address and the username correspond to an user in Deepser a new email should arrive at the email address provided. The email should look like the one given below:
If you click the Reset Password button or link you will be redirected to a new page where you can add your new password.
The criteria for the new password are:
After adding the password and clicking Reset Password button the password will be set to the one you provided and you will be redirected to the login page.
In Deepser it is possible to implement a user registration procedure to allow new users to register independently among the users present in Deepser.
Below, we will cover the procedure necessary to implement the creation of a registration form in Deepser.
Deepser allows you to create a registration form by combining one or more Step components.
To create a “Step” you will need to go to the “System -> Permissions -> user Registration -> Step” menu
In the screen that will open, you will need to click on the “Add Step” button.
Once you click the button, you will be redirected to the creation screen of a new step.
Below we briefly report the meaning of each field:
| Field | Description |
| Name | Step name |
| Position | Position in the step grid. |
| Label | Written that will appear to users when the step is uploaded. |
| Is Default step | Indicate if this is the step from which the recording will begin |
| Is Final step | Indicate if this is the step that will end the recording |
| Next step | Next step in the registration, null if the current step is the step that will end the registration |
| Check Token | Checks whether the verification token is present in the request. |
| Send Token | Submit the verification token |
| Token Duration | Token duration in hours and minutes |
| Mailbox | Indicates the mailbox with which the messages will be sent to the user during registration |
| Email Event | Email event associated with registration (if any) |
| StepData Formtemplate | Form template associated with the current step |
| Validate Expression | Custom code that allows you to validate the input data |
| Final Message | Final message that will be displayed by the user if the current step is set as the final step |
| Create User | Indicates whether a user will be created in this step |
| Create Active User | Indicates whether an active user will be created in this step |
| Send Reset Password | Indicates whether a password reset email will be sent to the user |
| Field Config | Mapping user principal fields to form template fields |
| User Create Expression | Custom code that will be used to create a user |
| Status | Indicates whether this step is active or not. |
In the successive lessons we will cover the creation of a registration form that allows a user to register himself and access the support, but only to users who belong to a company registered in Deepser, this to prevent external users from opening tickets without permission.
Before proceeding with the actual creation of the form, we must create a custom field that allows us to receive user input.
In the following example, we will see how to create a user only if the VAT number entered will correspond to one of the companies present in Deepser. For this example, we will assume that there is a custom field named “cust_vat_number” that will contain the VAT number of the company.
The Custom Fields will be addressed in another lesson, to go to the lesson related to the Custom Fields click here.
To create a custom field, we must go to: System -> Custom Fields.
Here we will have to click on the model “DeepRegistration – stepData”.
On the next screen, we will have to click on the “Add Field” button.
In the screen that will be displayed, will need to fill in the fields as follows:
Important is to set the “Column Type” and “Element Type” fields to text.
At this point, you will need to click on the “Save” button
Once this is done, we can proceed to implement the registration form.
In order to create the Registration Form we must go to the step creation menu to create a new step.
The Step Section is located under the “System-> Permissions – > user Registration -> Step” menu.
At this point, we give a name to our registration form by entering the desired name in the “Name” field
We define the “Position” field as zero.
Now we set the label that will be displayed on the registration screen by entering the desired text in the “Label” field.
Note that this field can contain text or even html with its css styles.
We define “Is Default Step” field to yes, in this way we are defining what will be the step from which the registration will begin.
Since in our example we have only one registration step, we also define “Is Final Step” to “Yes”.
Since in our example we have only one registration step we define “Next Step” as none, in the case of a multistep registration it will be possible to set what will be the next step, through this field.
Another important thing to notice is that to populate the field, you will first need to create a new step.
We set what will be the email box that we will use to send any Password change emails through the “Mailbox” field
Now we set which form template we want to display during registration using the field “StepData Formtemplate”
In the “Validate Expression” field, we can go to define the custom code that we will need to carry out checks on the validity of the data passed in input.
Within this field we are going to enter the following code:
/**Defining Variables**/
//Assigning StepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value og the cust_vat_number field to a variable.
$vatNumber = $stepData->getData('cust_vat_number');
//Assigning the value of the email field to a variable.
$email = $stepData->getData('email');
//if the email isn't in a valid format return an error to the user.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$this->addError("Email is not in a valid format");
}
//Retriving form the user collection all the users the have the username equivalent to the ginven e-mail.
$usersCollection = Deep::getResourceModel("deep_admin/user_collection")->addFieldToFilter("username",["eq" => $email]);
//Retriving form the user collection all the StepData the have the username equivalent to the ginven e-mail.
$stepDataCollection = Deep::getResourceModel("deep_userregistration/stepdata_collection")->addFieldToFilter("email",["eq" => $email]);
//If uone or more user or StepDatas where found retun an error to the user.
if($usersCollection->count() || $stepDataCollection->count()){
$this->addError("Email Already Registered");
}
/**If the company is present in Deepser we allow the registration otherwise throw an error**/
//Loading a company ginven the cust_piva field, if there is non company with this field this method retrive a new object.
$company = Deep::getModel("deep_company/company")->load($vatNumber,'cust_piva');
//If the returned object doesen't have the id or is null,return a error to the user.
if(!($company && $company->getId())){
$this->addError("We are sorry, but only employee of our customer can register an account");
}
In the field “Final Message” we will define the message that we will give to the user once the registration has been successfully completed.
Here, we will insert the following code:
<style>
.cust__msg{
margin-left: auto;
margin-right: auto;
display: flex;
flex-direction: column;
}
.cust__msg > *{
text-align: center;
box-sizing: border-box;
margin-left: auto;
margin-right:auto;
width: 100%;
}
.cust__msg .row{
display: flex;
justify-content:space-evenly;
padding-right: 30%;
padding-left: 30%;
}
</style>
<div class="cust__msg">
<h1>Success</h1>
<p>Congratulations, your account has been created!.</p>
<div class="row">
<div class="col-sm-3">
Username:
</div>
<div class="col-sm-3">
<?php echo $this->getStepdata()->getData('email');?>
</div>
</div>
<div>
<h6>We have sent you an email with the link to reset your password.</h6>
</div>
</div>
At this point, we will have to define to create a user by defining the field “Create User” to”Yes”.
Now, we will define if the user will be an active user by defining the field “Create Active User” to “Yes”
Now we will define whether to send the user an email at the end of the procedure that will allow him to reset the password using the “Send Reset Password” field.
Now, in the “Field Config” field we will define the mapping of the user template fields with the form fields. To add a new field to map with the form data simply click the “+” button.
We have defined the users’ field as follows:
In the “User Create Expression” field, we can define custom code that will allow us to set the user’s attributes or in general to perform actions when creating a new user.
In this field, we will enter the following code:
//getting the datas from the form
$stepData = $this->getStepdata();
// assigning the end user role to the created user by passing the role id
$this->getUser()->setData("role",73);
Finally, we set the “Status” field to Enabled (If it wasn’t already set to Active).
At this point, you will need to click on the button “Save” or “Apply”
To modify the form template that will be displayed during registration, you will need to click the “Preview” button
At this point, you will need to click the pencil button:
And then go to the StepData tab:
Here you can enter the fields by dragging them from the right column into the grid
Finally, you will need to click on the Save Button.
During the registration phase it may be necessary to validate the user’s email, to do this you can send a token that will allow you to verify the user’s email.
Taking as a basis the previous example, we create another step, this time ignoring the part related to the creation of the account, in addition we will configure the sending of the token.
In order to send the verification token to the end user it will be necessary to create an email event with its associated template form that will be used by Deepser to send the email to the user who is registering.
To create a custom mail event you will need to go to the System -> Tools -> Email -> Templatemenu.
Then you will need to click on the “Add MailTemplate” button.
In the screen that will open you will need to define a name for the template, to do this, simply enter the desired name in the “Name” field.
Next, we will define a code for the template, filling in the “Code” field.
At this point, it will be possible to insert in the “Subject” section the php code that will compose the subject of the email.
You can use the following code as a reference to compose the subject of the email:
<?php echo Deep::helper('deep_email')->__('DEEPSER - Confirm your Registration')?>
Now it will be possible to insert in the section “Body”, that will represent the content of the message, the PHP / HTML code that will serve to generate the body of the mail.
You can use the following code as a reference when creating the body:
<?php
$username = $this->getModel()->getEmail();
$firstname = trim($this->getModel()->getFirstname());
$lastname = trim($this->getModel()->getLastname());
$tmpFullname = $firstname . $lastname;
$fullname = $fullanme != "" ? $tmpFullname : "user";
$url = $this->getModel()->getTokenStepUrl();
?>
<?php $this->includeTemplate("header") ?>
<!-- Start of Main Content -->
<tr style="">
<td bgcolor="#FFFFFF" align="center" style="">
<table width="100%" align="center" cellpadding="0" cellspacing="0" border="0" class="devicewidth" style="">
<tbody style="">
<!-- Start Spacer -->
<tr>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td class="h26" height="36" style="font-size:1px; line-height:1px;"> </td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
</tr>
<!-- End Spacer -->
<tr style="">
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td class="mktEditable content mktEditable content" id="edit_text_1" valign="middle" style="font-family:Calibri, Helvetica, sans-serif; font-size:16px; color:#505050; text-align:left; line-height:25.6px; font-weight:normal; text-transform:none;">
<p>
<br>
<?php echo Deep::helper('deep_email')->__('Dear %s',$fullname);?>,<br>
<?php echo Deep::helper('deep_email')->__('Please confirm your registration by clicking the link below'); ;?><br>
</p>
</td>
</tr>
<!-- Start Spacer -->
<tr>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
<td height="30" style="font-size:1px; line-height:1px;"> </td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </td>
</tr>
<!-- End Spacer -->
</tbody>
</table>
</td>
</tr>
<!-- End of Main Content -->
<!-- start of Button -->
<tr style="">
<td bgcolor="#FFFFFF" align="center" class="mktEditable" id="edit_cta_button" style="">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td class="w22" width="41" style="font-size: 1px; line-height: 1px;"> </td>
<td align="left">
<table class="button" cellpadding="0" cellspacing="0" border="0" align="left" bgcolor="#0080ff" style="-webkit-border-radius: 4px; -moz-border-radius: 4px; border-radius: 4px;">
<tbody>
<tr>
<td width="518" align="center" valign="middle" height="65">
<span style="color: #ffffff; text-decoration: none;">
<a class="mobButton mktNoTok" href="<?php echo $url ?>" style="font-family: Calibri, Helvetica, sans-serif; font-size: 16px; color: #ffffff; display: block; height: 65px; mso-line-height-rule: exactly; line-height: 65px; font-weight: normal; text-decoration: none; text-align: center!important;" target="_blank" title="Link al ticket">
<?php echo Deep::helper('deep_email')->__('Confirm the registration')?>
</a>
</span>
</td>
</tr>
</tbody>
</table> </td>
<td class="w22" width="41" style="font-size: 1px; line-height: 1px;"> </td>
</tr>
</tbody>
</table>
</td>
</tr>
<!-- end of Button -->
<?php $this->includeTemplate("footer") ?>
And click on the “Save” or “Apply” button:
To create a custom mail event, you will need to go to the “System -> Tools -> Email -> Event” menu.
At this point, you will need to click on the “Add Event” button.
The following page will be displayed:
At this point, it will be necessary to give a name to the event by filling in the “Name” field.
We define Whether to send attachments, changing the value of the field “Send Attachments”, in our case we set it to “No”.
Now, in the “Email Template” field, we select the template created in the previous point of this guide.
In the “Event Trigger”section, select “DeepUserregistration-StepData” in the “Model” field
In the “Event Expression” entry.
We insert the following code :
return true;
In the “To” section
We insert the following code :
/**Configuring the language with local **/
$this->changeLanguage($this->getModel()->getCustLocale());
/**Getting the email from the current model**/
$this->addTo($this->getModel()->getEmail());
At this point, we can go to click the “Save” or “Apply” button
Now the event will have been saved.
To create a new form template, you will need to click on “Preview”.
Here, you will need to click on the button with the arrow icon.
Now you will need to click on “New Formtemplate”
In the screen that will open, you will need to enter in the field “Enter Template Name” the name of the new form template.
Next, you will need to click on “Save”.
At this point, the new form template will be created.
To create a new form template, you will need to click on “Preview”.
Here you will need to click on the button with the pencil icon.
Here you will need to go to the “Fieldset”: “Step data”.
At this point it will be necessary to locate the field that we want to make mandatory and click on the corresponding gear icon.
In the screen that will open you will need to change the field “Required” and set it to “Yes”.
Now you will need to click on the “OK” button on the field configuration screen.
Finally, you will need to click on the “Save” button in the form configuration window.
At this point the field will be mandatory.
Deepser evaluates form templates from the highest priority to the lowest priority form templates.
The priority of the form templates is therefore important to define which form template the user will see.
To set the priority, you will need to go to the arrow key.
Now click on the template you want to edit.
At this point, click on the button with pencil icon.
Now you will need to click on the “Edit Rules” button and then subsequently set a value in the priority field.
Finally, click on the “Save” button.
For this example we will use as a basis the step created in the previous lessons, in addition we will create two form template the first named “First” with the email fields, Firstname and Lastname and the second named “Second” with only the Vat Number field (cust_vat_number) created in the previous points of lessons of this guide.
Let’s go to the Step section and click on the “Add Step” button
In this new we are going to configure the field “Name”, in this field we will enter the name we want to give to the step.
We configure the field “Position” to 0
We configure the field The “Label”, this field will contain the inscription that the user will see when he arrives at this form.
We configure the field “Is Default Step” to “Yes”.
We configure the field “Is Final Step” to “Yes”.
We configure the “Next Step” field on the step created in the previous points (User Support Registration).
We configure the field “Check token” to “No”.
We configure the field “Send Token” to “Yes”.
We set the “Token Duration”field, to an hour or at least to the time that we believe to be sufficient to perform the registration.
We configure the”Mailbox”fieldwith the exit mailbox that we will use for registraction.
We configure the “Email Event”fieldwith the mail event created in the point above.
At this point we set the field”StepData Formtemplate” form template that we want to use in this first step, in the template form we set all the fields that must be filled in as mandatory, in this way the user will have to fill them in order to continue, you can refer to the previous topic for the configuration of the form field as mandatory click here to go to the guide.
To create a custom form template you can follow the guide found in the previous article, click here to go to the guide.
We can configure the fields “Create User” and “Create Active User” to “No”.
In the “Validate Expression” field, we insert the following code to verify the form template.
/**Variables Initialization**/
//Assigning the stepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value of the email field to a variable.
$email = $stepData->getData('email');
/**Verifications**/
//if the emil isn't in a valid format return an error to the user.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$this->addError("Email is not in a valid format");
}
//Retriving form the user collection all the users the have the username equiva-lent to the ginven e-mail.
$usersCollection = Deep::getResourceModel("deep_admin/user_collection")->addFieldToFilter("username",["eq" => $email]);
//Retriving form the user collection all the StepData the have the username equivalent to the ginven e-mail.
$stepDataCollection = Deep::getResourceModel("deep_userregistration/stepdata_collection")->addFieldToFilter("email",["eq" => $email]);
//If uone or more user or StepDatas where found retun an error to the user.
if($usersCollection->count() || $stepDataCollection->count()){
$this->addError("Email Already Registered");
}
In this case we can leave the field “Field Config” as we are going to manage the creation of users in the last step
We can leave the”User Create Expression”field blank because we will not create users in this step.
At this point, Click on the Apply or Save button.
In the end, the step will be saved.
Let’s move now on to the final registration step.
In this step, we are going to change the”Check Token”field by setting it to “Yes”.
And we will configure the form template that will be associated with this template using the field “StepData Formtemplate”.
At this point, we modify the Form Validate Expression field to perform the only validation of the “Vat Number” (in the case of example).
**Defining Variables**/
//Assigning StepDatas to a variable.
$stepData = $this->getStepdata();
//Assigning the value og the cust_vat_number field to a variable.
$vatNumber = $stepData->getData('cust_vat_number');
/**If the company is present in Deepser we allow the registration otherwise throw an error**/
//Loading a company ginven the cust_piva field, if there is non company with this field this method retrive a new object.
$company = Deep::getModel("deep_company/company")->load($vatNumber,'cust_piva');
//If the returned object doesen't have the id or is null,return a error to the user.
if(!($company && $company->getId())){
$this->addError("We are sorry, but only employee of our customer can register an account");
}
Note: this form template must have a higher priority than all the others
At this point, you will need to click on the “Save” or “Apply” button.
To enable the possibility of registering through the registration form, it will be necessary to go to the System -> Configurations -> Admin -> Security menu.
Here you will need to change the field “Enable User Registration” and set it to “Yes”.
Now, to save the changes, you will need to click on the “Save Config”button.
At this point, the registration link will have appeared on the main Login page:
Deepser natively supports integration with the LDAP protocol.
LDAP is a protocol for centralized resource management.
Deepser’s LDAP integration allows you to easily import users and or groups containing users that you will need to be enrolled to be managed/enabled in Deepser from an existing LDAP installation.
Note that Deepser synchronizes resources with LDAP in read-only mode and can independently manage the update of states or generally modified parameters on the LDAP Resources placed in the LDAP controller, this translates into the fact that if a user is moved to group or disabled or in general changes are made to the user on the LDAP controller the same changes, in a standard case, will be replicated on Deepser.
To configure an LDAP integration on Deepser you will need to go to the System -> Permission -> LDAP Integration menu
In the screen that will open, you will be able to view the LDAP integrations already configured and configure new ones.
To configure a new integration, you will need to click on the Add LDAP button.
After that the following screen will open:
Below are the fields present and their meaning:
| Field | Description |
| Show In Login | This field indicates whether this LDAP integration will be visible on the login page |
| Is Default | Indicates whether this LDAP integration will be the one selected by default in the list on the login page |
| Name | LDAP Integration Name |
| Domain Controller | The address at which to find the domain controller. |
| Cron Expression | Cron expression that indicates how often the integration will be performed. |
| Status | Indicates whether this integration is active or not, if it is not active the synchronization will not be performed. |
| Base DN | Domain base name, this field indicates the point below which Deepser will have visibility in the domain forest. |
| Time-out | Indicates the maximum time within which if a request is not answered, the request must be considered expired. |
| Use SSL | Indicates whether the domain controller uses S.S.L. encryption |
| Use TLS | Indicates whether the domain controller uses T.L.S. encryption |
| Follow Referrals | This field indicates whether to follow the referral links generated by the LDAP controller. Referral links are links that indicate that the server you are querying does not directly own the requested resource, but has a reference to the server or domain that owns that resource. |
| Admin Username | Username of the user that Deepser will use to read domain’s users. |
| Admin Password | Password of the user account that Deepser will use to read access the Domain Controller. |
In the Users Configuration section, you will define how users will be synchronized in Deepser.
Below are the fields in this section and their meaning:
| Field | Description |
| User Name Attribute | Indicates which field of the response obtained from the domain controller will contain the user’s name |
| User RDN Attribute | This field is the field that indicates the path relative to another entity (parent) of the resource in the Domains Forest . ES: distinguishedname. |
| User Fields | This field is used to map the relation between domain user’s fields and user’s fields in Deepser |
| User Object Filter | This field is used to specify an LDAP query, this will serve as a filter to retrieve only users who match the search criteria. |
| Account Prefix | Account prefix e.g.: “EXAMPLE\<username>”. In this case “EXAMPLE\” is the account prefix. |
| Account Suffix | Account suffix ex: “<username>@example.local”. in this case “@example.local” is the account suffix. |
| Disable Users | This field indicates whether users created on AD as disabled should be imported as disabled or not. |
| Custom Code | Custom code to indicate how user field values imported from integration are assigned. |
In the Groups Configuration section, you will define how groups will be synchronized in Deepser.
Below is a list of the fields present and their meaning:
| Field | Description |
| Group Enable | This field is used to enable the import of groups into Deepser from the forest. |
| Group Base DN | Indicates which is the name of the base domain in which the groups reside (e.i.: cn=exemple, dn=com) |
| Group Name Attribute | Indicates which field in the object returned by the request to the domain controller will contain the name of the group. |
| Group Members Attribute | Indicates which field in the object returned by the request to the domain controller will contain the list of users who belong to the group |
| Group Object Filter | This field is used to specify an LDAP query, this will serve as a filter to retrieve only the groups that match the search criteria. |
| Group Fields | This field is used to bind domain group fields to group fields in Deepser |
Once the fields have been configured, you will need to click on the “Save” or “Apply” button.
At this point, by clicking on the “Check LDAP” button, you can check if the integration works correctly.
If the integration works correctly, a green banner will be displayed in the upper right corner of the page.
In case of error, you will see a red banner in the upper right corner of the page.
SSO (Single Sign On) is the technology that allows you to use delegated authentication to access Deepser.
In Deepser you can configure the sso using “Google” or “Azure” as the preconfigured provider.
Alternatively, you can also configure other delegated authentication providers using the Client OAuth configurations, but in this case you will need to manually configure the authentication parameters.
To configure a new ss integrationor you will need to go to the System->Tools->OAuth->Client menu
Here you will need to click on the “Add Client” button:
As a first step you will need to assign a name to the client and click on the “Save” button to get the “Redirect Uri” that will be needed to configure the provider->side SSO.
After that, you can continue the configuration.
In the screen that will open you will be able to implement the configurations to implement SSO.
Below are the fields with their meaning:
| Field | Description |
| Name | Identification name of the OAuth Client |
| Provider | OAuth provider. This field can take 3 values: Google, Azure, Generic. In case this field is set to Google or Azure it will be possible to ignore the configuration of the fields: {{Insert list of fields already configured}}. If the field is configured to Generic you will need to manually specify the configuration of the fields. |
| Type | This field indicates the type of Client that is configured. The possible types are: User, Mail or Calendar. The type to be used for sso providers is: user. The Mail type is used to indicate an OAuth client that will interface with a mail provider. The Calendar type Is used to interface Deepser with an OAuth provider that provides a Calendar service. |
| Client ID | This field must be enhanced with the client id that will be provided by the Delegated Authentication provider. |
| Client Secret | This Field must be configured with the client secret that will be provided by the delegated authentication provider. |
| Scope | This field indicates the scopes to which the client will request access to the resources. |
| Url Authorize | Authorization url. this parameter is the endpoint to call to obtain authorization this parameter must be provided by the authentication provider |
| Url Access Token | It is the ‘URL base’ to which the parameters are added to request the authentication token (post-authorization step). You do not need to compile it for Google or Azure providers, the default values will be used. |
| Url Resource Owner Details | Base url of the server responsible for managing resources. This parameter must be formed by the provider. |
| Proxy | This field, if enhanced, will use the proxy indicated to forward requests for Delegated authentication. |
| Verify | If you have configured a proxy you can enable or disable SSL check. You do not need to compile it for Google or Azure providers, the default values will be used |
| Status | This field indicates whether the client is Deepser enabled or whether the client is disabled. Please note that if the client is disabled Deepser will not use it nor will it display it among the usable clients. |
| Scope Separator Char | Scope separator character, indicates which character the provider uses to indicate the end of one scope and the beginning of another. |
| User Data Source | Users’s data source url. |
| Endpoint User Data | The endpoint to which Deepser will make requests to obtain user data. |
| Related LDAPs | Indicates whether LDAP integrations are connected to this client |
| Username Attribute | This field indicates the name of the object field returned by the identity provider that will contain the username. |
| User Fields | Maps the user’s internal attributes with those retrieved from the specified user data endpoint. You do not need to compile it for Google or Azure providers, the default values will be used. |
| User Create Expression | Scripting area that allows you to specify how Deepser should behave when creating a new user and how to synchronize this user on the sso provider. |
| User Update Fields | Scripting area that allows you to customize the update of a user in case it is modified on the sso provider. |
| User Update Expression | PHP script to customize a user’s update,in the case of an SSO integration, for example. It is not necessary to fill it in for the Email Box type. |
| Login Button Caption | Text that will be displayed on the login button that will be created on the deepser login screen. |
| Login Button Icon | Image on the login button that will be displayed on the Deepser login page |
At this point the client verification key will be displayed, it will be necessary to click the validate button.
At the end of this configuration, you will need to click on the “Apply” button
You will then be redirected to the login screen of the Delegated authentication provider you are configuring.
At the end of the wizard if everything went well you will be redirected to the Deepser OAuth client screen with a message that will indicate that the configuration has taken place successfully.
In case of errors on the same page the error message will appear at the top.
The Provisioning functionality allows you to automatically create in Deepser the users and groups registered within your Microsoft Azure environment, if the latter have been enabled for the SSO application.
Therefore, instead of being created/updated only at each login, it is possible to perform a synchronization between the users present in Azure who must log into Deepser, and the related User records in Deepser.
This functionality can be performed only once, by clicking on the “Provision” button at the top right (mainly used for testing the configuration), or even be scheduled to run several times a day by configuring the Cron expression.
To configure this functionality in Deepser, in addition to what is seen in the “Configure SSO” section, within an Azure SSO client, it will be necessary to go to the “Provisioning” tab and configure the necessary parameters.
Below are the fields with their meaning:
Field | Description |
Provisioning enabled | If toggled on, provisioning is enabled |
Provisioning Provider | If “Azure” is selected, |
Cron Expression | If “Azure” is selected, some specific fields will appear and others will become required |
Tenant ID | Azure Tenant ID. Required for Azure provisioning provider. |
User Provisioning Mode | You can select the way in which users will be synchronized. Required for Azure provisioning provider. |
Disable Users | If toggled on, local user status will be updated with provisioned user status. |
Disable Deleted Users | If enabled, if the provided user has been deleted, or does not match the filters, or is removed from the users assigned to the application, disables the relative users in Deepser. |
User Filter | If provisioning provider is Azure, write filters in query string format, ie: $filter=surname eq ‘Foo’ $filter=jobTitle eq null $filter=userPrincipalName in (“Foo”,”Bar”) $search=”surname:Foo” For documentation, see Microsoft Graph documentation |
User Group Filter | Only provision users which are members of these specific groups. Groups are filtered by the field specified in Group Name Attribute |
Group Name Attribute | Specify which group data attribute will be used as the name of the group. It is also the name of the group attribute to filter by in the User Group Filter and in the Group Filter.If no value is provided: Azure provisioning provider, will use displayName by default. |
Group Provisioning Mode | You can select the way in which groups will be synchronized. Required for Azure provisioning provider. |
Group Provisioning Enabled | If toggled on, groups will also be synchronized. |
In Deepser you can set up SSO using Azure as the default provider.
This article explains how to configure Deepser and Azure, to allow SSO and User Provisioning via Azure Account in Deepser.
It includes 3 steps:
Note: SSO Login can be configured only on HTTPS protocol.
To configure a new SSO integration you will need to go to the System >Tools >OAuth >Client menu
Here you will need to click on the “Add Client” button:
As a first step you will need to assign a name to the client and click and set the following fields as follow:
Then you can click on “Apply” or “Save” button.
After the saving you can be able to copy the “Redirect URI” from the following field:
The “Redirect Uri” will be needed to configure the provider->side SSO (Azure in our case).
So, the first step of Azure SSO Configuration in Deepser is concluded. The next steps will be Azure Configuration and then the completion of the configuration in Deepser.
In this step we can manage the configuration from provider side (Azure).
You will need to login as administrator to the Azure portal: https://portal.azure.com/.
Note: We recommend performing all configurations in incognito mode or in a browser without any active logins to Azure/Outlook 365 to avoid user conflicts during the configuration.
Search for app registrations and open it
You can proceed with a new APP Registration (API), by clicking on “New registration” button:
On App Registration we can proceed entering the following information:
Redirect URI as “Web” type (Previously generated and copied from Deepser Oauth Client)
In conclusion you can click on “Register” button.
You can now access your newly registered application and navigate to ‘Manage > Authentication’ from the menu.
From here, you can confirm that the correct Redirect URI is set under the ‘Web’ section, and enable the following tokens:
Under “Manage > Certificates & secrets” in the menu, you can create a secret. During the configuration process, you’ll need to set its expiration time and copy its value, which will be used later to complete the configuration in Deepser.
The copied secret value will need to be entered into the field “Client Secret” on the oauth client record in Deepser:
Notes:
Under “Manage > Token configuration” from menu you can set the following optional claim IDs by clicking on “Add optional claim”:
When adding the claims, remember to check the box for “Turn on the Microsoft Graph email, profile permission (required for claims to appear in the token)”:
Under “Manage > API permissions” in the menu, you can add the following permissions for Microsoft Graph and then run the “Grant admin consent” action:
Also at this stage, if you need to Provision user/groups in Deepser, you need to add permissions for:
Click on “Add a permission” to open the permission selection prompt:
Then select “Microsoft Graph” as API permission to use:
From that screen you can choose Delegate or Application permissions and use the search field for research the desired permission to add:
After adding all desired permissions, you can run Grant admin consent command:
Now you can switch to “Enterprise Applications” by searching for it in the global search:
Then search and access your new registered application clicking on it:
After access to it, go to its properties and change the following configurations:
To enable provisioning for users and groups in Enterprise Application you can add your desired users and groups:
Now that everything is configured in Azure, you can go back to the Oauth Client in Deepser.
Before going back to the Oauth Client in Deepser, we can note down all the Azure information to be used in Deepser Oauth client configuration. Below is a summary of the Azure information to be reported in Deepser:
The “Secret value” will be entered “Client Secret” field in Deepser (“General” Tab):
Notes:
The “Application (client) ID” will be entered “Client ID” field in Deepser (“General” Tab):