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, 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.
To create a new user in Deepser you will need to go to the menu System -> Permissions -> Users
In the screen that will open, you will need to click on the “Add User” button
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 username. |
| 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 exemple the Users role, who by default see 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.
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 presents 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 on that has visibility and one in that does not have it, then the resource will be visible.
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.
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.
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:
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.
Create an APP Registration (API)
Enter Name, Supported Accounts, and Redirect URI of the OAuth client configured in Deepser.
Create an Authentication with Platform WEB and put the url of the application (only https) – Type claim ID Tokens
Create a secret
Set claim IDs
Add permissions for Microsoft Graph and then run the Grant admin permission
Now switch to application management in ENTERPRISE APPLICATION
In User and Groups add the enabled users
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 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, 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 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 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.
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, 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.
In Deepser, all entities that can be processed by escalation rules have a “Level” attribute that serves as a filter to indicate which escalation rules should be evaluated on that entity.
Escalation rules process only entities whose level is equal to the “Level” attribute set in the rule itself or lower, after their execution they set the “Level” attribute of the processed entity to the value indicated in the “Next Level” field of the rule.
This mechanism allows you to make a skimming on the rules that will have to be evaluated for each entity, allowing you to define rules that must be evaluated only once for each entity of the selected type.
To configure an escalation rule to run only once, it will be sufficient to configure the “Level” field of the escalation rules to the desired level (by default 0) and the “Next Level” field of the rule to a value higher than that of the “Level” field for example to 1 in the case of default.
To make sure that an escalation rule is executed potentially several times on the same entity, it will be sufficient to set the “Level” field and the “Next Level” field to the same value.
This will cause the rule to evaluate that ticket potentially several times (at most 1 per execution of the rule itself), if the “Level” of those entities were changed by other rules, the behavior of the rule that we are configuring may not be what was expected.
For this reason, the advice we give is always to evaluate the rules as a whole to understand if one or more rules can conflict (intentionally or not).
Suppose the existence of 2 escalation rules: “A” and “B”, the “A” rule takes charge of all tickets that have not been assigned for more than two hours and sends an email notification (the implementation of these types of rules will be covered in subsequent lessons), setting the “Level” field of the processed entity to 0 from 0.
Rule B instead takes charge of all tickets that have not been assigned for more than 4 hours and sends an email also setting the priority to “Critical” and changing the level of the entity to 1.
In this case, if a ticket’s processed by rule “B”, which includes more general conditions, it is intended not to be processed by rule A.
In general, however, it is necessary to pay attention to the escalation rules as a whole.
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.
1a – Access the Password module from the main Deepser menu.
1b – Else access it through the drop-down menu of the user portal.
2 – Click on the Add Password button
3 – You will see the form for the password creation.
The fields have the following meaning:
| Field | Meaning |
| Name | Brief description of the password. |
| Username | Username. |
| Address | Address of the device /URL of the site |
| Company | Field used to connect the password to an existing Deepser company. |
| Password | The Password to store. |
| Generate | Button to generate a random password. |
| Key File content | Cryptographic key to be stored, inserted as text content. (e.g. to store an API key). |
| View Groups/View Users | Allows to select multiple groups or individual users who will be able to view the password. |
| View and Edit Groups/View and Edit Users | Allows to select multiple groups or individual users who will be able to view and edit/delete the password. |
| Use Groups/Use Users | It allows to select multiple groups or individual users who will be able to display the password in the forms that will use it, implemented by means of a custom Deeppassword field. |
| Use Password | Enable the display of the password within the modules that implement it. |
| Hidden | It makes the password not recoverable by passphrase from users, but still usable internally by the software, for example for scanning. |
| Status | Indicates the status of the password (Enabled/Disabled). |
| Expiration Date | Defines an expiration date for the password, can be implemented as a reminder for escalation rules. When the expiration date is reached, the Expired field is automatically set to ‘Yes’. |
| Expired | Indicates if the password has expired. |
| Updated by | Indicates which user is responsible for the latest password update. |
| Is private | Indicates if the password is private. |
| Description | Description and/or additional notes on the password. |
| Category | The category field can be valorized only if there are categories visible to the DeepPassword model. |
3a – To generate a random password, click the Generate button.
3b – Select the relevant parameters, enter a length, and then click on Generate.
3c – Fill in the relevant fields (in the example a password is configured for a cloud service, then the fields Name, Username, Password will be highlighted, this will be visible to all groups, but only Second Level IT administrators can change it).
Note: To the left of the Generate button there is a security indicator for the password entered.
4 – Now the password is correctly saved and viewable by selected users and groups
To configure a new import procedure, please go to the menu: System > Tools > Import.
In the first page after clicking on the menu, you can see a grid of all Imports already configured in your Deepser.
To see the configuration for a specific import, click on the row in the grid. Press ‘Add Import’ to create a new one.
Then we can see the Import configuration form:
The Fields have the following meaning:
| FIELD | MEANING |
| Name | Name of the Import. |
| Model | Model of the entities that are going to be imported into Deepser (Operations, CI, Companies etc.). |
| Type | Format of the source file containing the records to be imported in Deepser. |
| Has Header (Yes/No) | The first row of the file is an header. If Yes, Deepser will ignore the data of the first row of the Excel File. |
| Cron Expression | If the first row of the Excel file is a document header, it cells can be automatically recognaised as entity fields, this comes handy during the binding process |
| Status | If Enabled the import will run, otherwise not. |
| File Path | It is used to upload the source file containing the records to be imported. |
| Path Expression | It is used to dynamically change the name of the file, containing the data to be imported. We will explain this field with an example, below in this document. |
| Entity – File – Code | In this field there is the configuration of the ‘File Column – Entity Field’ binding. Entity: Model field; File: File column; Code: script to perform specific manipulations of data on the column value (e.g.: format a date, convert a value, etc.), executed during the cell evaluation. |
| Before Run | Custom PHP code to be executed before the import procedure starts. It is used (see examples below) to pre-load data in memory, in order to avoid subsequent massive SQL queries to the DB. e.g.: Load the content of a DB table inside an Array. This action can then be used during the import, to avoid querying the database for every Excel file row. |
| Before Row | Custom PHP code to be executed before each Excel file row is imported. It is used (see examples below) to dynamically change the values of the row imported. e.g.1: for every row imported we want to set the status as “New”. We can specify that inside this field. e.g.2: we want to load a record of the DataBase instead of importing a new record. We can load the record from the DataBase here, or read the record from the Before Run Array, representing the data on the DB Table. |
| After Row | Custom PHP code executed after each row, as soon as every single record has been saved. It is executed multiple times after every row insert/update. |
| After Run | Custom PHP code executed after all Excel file rows have been imported. It can be useful to perform custom tasks at the end of the import. |
In this guide, we will see how to use a relation grid field to add and remove elements related to an entity.
To add a ci to an operation you will need to go in the operation itself, for example an incident with a specific ID.
Inside the ticket, there is a TAB called Relations.
After the creation of a custom relation between the CMDB model and Operation model, the following screen will then open:
You will need to click on the “Add” button.
Now the following screen will open:
Here we will have to go and tick the box placed in correspondence of the platform that we want to go to d add and select from the menu, located at the top left the item “Add”:
Now we must click on “Submit” to confirm.
At this points a confirmation alert will appear on which we will have to click the “OK” button:
At the end we must click the close button, located in the lower right corner and we will see the added platform:
To remove an operation will be necessary to click on the check placed at the operation to be
removed and from the menu placed in the upper left corner of this field we must go to click the item “Delete”:
At this point a confirmation popup will appear on which we will have to click on the “Ok” button:
In the end, we will see that the operation will have been removed correctly.
In Deepser the Services are the services offered by the organization.
The Service module collects all the data of user requests, sorts records by priority, expiration date, creation date and organizes them by Type, and category.
The user portal shows the types of requests that can be submitted by end users to the support service.
In the backend instead, there will be in the sidebar a Service section That will count all the types of service that the group is enabled to view.
The module configuration, according to Deepser thought, is accessible from the System>Asset Configuration section visible only to System Administrators to ensure maximum security and control.
To consult all the devices added to ‘IT Asset Management‘ module, go to the Asset>Device section in Deepser back-end.
From there you can see the Devices and organize them into by configuring your custom grids and access the form containing their data to modify them if it is necessary.
From this section, you can download the Agent (Agent installation procedure will be illustrated in the specific section) or manually create the Devices.
By clicking on a Device in the grid, you can access the form containing its data, such as:
To consult software added to ‘IT Asset Management’ module, go to the Asset>Software>Software in Use section in the Deepser back-end.
The software installed on collected devices is automatically added to Deepser.
You can also organize software by configuring your custom grids and also manually add new records.
By clicking on a Software entry in the grid, you can access the form containing its data.
To create a new user in Deepser you will need to go to the menu System -> Permissions -> Users
In the screen that will open, you will need to click on the “Add User” button
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 username. |
| 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 exemple the Users role, who by default see 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.
Sla calendars are the basic tool that allows Deepser to correctly process timelines and deadlines for terms of service.
In this lesson we will cover sla calendars in Deepser in more detail.
In Deepser the sla calendars are used to define the working times.
Since the SLAs allow you to define objectives within which actions must be carried out, the calendars allow Deepser to tread these objectives taking into account any midweek holidays or non-working days or weeks of suspension of activities for the company.
Note that Deepser already has a default calendar for SLAs, but it is advisable to check its configuration since the working week may vary depending on the country or company conventions.
To create a new calendar, you will need to Go to the menu: System -> Service Design -> Sla -> Calendar
At this point, you will need to click on the “Add Calendar” button.
Now both will open the following screen:
To proceed to create the calendar, you will need to fill in the “Name” field, set the correct Timezone and click on the “Save” or “Apply” button to save the calendar.
To configure the working week, you will need to Go to the menu: System -> Service Design -> Sla -> Calendar
At this point we will have to click on the calendar that we want to go and edit.
To configure the work week, you will need to configure the Working Week section.
To do this it will be necessary to fill in the first field with the day we want to configure in this case on Monday, in the second field we will enter the start time of Activity, in the third field the minutes of start of activity.
Similarly, in the third and fourth field, we will enter the time of end of activity.
To configure the afternoon working hours, we proceed in the same way.
At this point, the result will look like this:
We can now proceed in the same way for all working days of the week.
Once you have finished this step, you can click the “Save” button to save your changes.
To configure public holidays, you will need to go to the menu: System -> Service Design -> Sla -> Calendar.
At this point, we will have to click on the calendar that we want to go and edit.
Now in the Holidays section.
We will configure the first field with the name of the holiday, in this case “Christmas”, in the field next to it, we set the date through the selector that will appear, to confirm it will be necessary to click on the “Add” button.
Once done, the result will look like this:
It will be possible to proceed in the same way for all the public holidays present.
Finally, you will need to click on the “Save” button to save the Changes.
Emails are integrated into the operations of service management.
With the appropriate configuration of email events, messages are automatically generated to notify customers, technicians or operators.
Through the message subject Deepser can also recognize incoming emails that refer to an existing entity in Deepser and associates them.
In order to see all the email messages associated with, for example, a service operation and/or its related entities (Comments, Worklog or Task) there is a dedicated field, the Email List.
By default this field is added to the operations screen, in the Email tab.
From the Email List field you can understand which emails are incoming and which are outgoing.
Email List also shows: subject, date of receipt or sending, sender and recipients.
By clicking on the “lens” icon, you can view the message body.
Most of the time you want that to each comment, added to a service operation, corresponds an email notification send to other actors. Deepser proposes this configuration as default.
If, for example, a technician in charge of the resolution of an issue needs more information from the user, he can request it by adding a comment inside the issue.
Deepser then sends an email, containing the technician’s request, to the user who will respond with the required information.
The user’s email will be “linked” with the issue and a comment will be created from its content.
The technician will receive a notification from Deepser containing the user’s response and will then be able to complete the issue resolution activities and close it.
The back-end screen of Deepser is organized into areas.
Note: the back-end is accessible only by Administrators, Agents and Key Users. End Users can only login to the User Portal.
1 – In Deepser you can access and consult the Knowledge Base from 3 separate entry-points:
2 – At this point the grid containing the Knowledge Base will open, click on the View button to open the KB you want to consult.
3 – When the Knowledge Base is opened, its description/introduction is displayed.
You can navigate through the articles via the left-hand summary.
The tasks in Deepser as mentioned in the previous article are divided into categories.
In this article, we are going to analyze the procedure necessary to create a new type.
To create a type of task, you will need to go to the menu: System->Tools->Task->Task Type.
At this point, the following screen will open:
Now you will need to click on the “Add Type” button.
Now the following screen will open:
Below are the fields and their value:
| Field | Description |
| Name | This field represent the name of the task type. |
| Position | This field represent the position that this type will have in the list of tasks. |
| Class | This field represents the class. There are 3 types of tasks: Task, Contact, Phone. For a generic task, we recommend the task class. |
| Status | This field set the status enabled or disabled. |
| Icon Class | This field allows you to define the class icon of this type of task. |
| Icon Color | This field allows you to define the color icon of this type of task. |
| Enabled Models | This field allows you to define on which Deepser entities these tasks will be visible (and associated). |
| Form Expression | This field allows you to define the form that will open when you click the button to create a new task. Note that if this field is empty, the form for creating a new task will also be empty. For the configuration of this field you can refer to the course Developer task available at this link https://docs.deepser.com/courses/deeptask-advanced/lessons/task/topic/form-configuration-of-task-types/ |
| Form Portal Expression | This field allows you to define the form that will open when you click the button to create a new task in the user portal. Note that if this field is empty, the form for creating a new task will also be empty. For the configuration of this field you can refer to the course Developer task available at this link (as above) |
Once you have filled in all the fields, you will need to click on the “Save” or “Apply” button.
In this example, we are going to create a task class.
Use “Font Awesome” for the icon class.
Note that this example will produce a task class without a form expression.
So,the form, that opens when you click the task creation button, will be empty.
To configure the form, please refer to the corresponding guide in the Task Developer course accessible at this address (as above).
To create a type of task you will need to go to the menu: System -> Tools -> Task -> Task Type.
At this point, the following screen will open:
Now you will need to click on the “Add Type” button.
Now the following screen will open:
In the “Name” field, we are going to enter “Demo Task”.
We can leave empty the “Position” field.
Now, let’s configure the “Class” field as “Task”.
Now set in the “Icon Class” field the value “fab fa-centercode”.
In the “icon Color” field, we now enter the desired color, in our case”#7FFFB7″.
Finally, select “Deep Service – Operation” in the “Enabled Modules “field to create task inside the Service Module.
As the last step, we must click on the “Save” or “Apply” button.
At this point, the task class will be saved and will become visible inside tickets.
By definition, a workflow is the sequence of steps involved in moving from the beginning to the end of a working process.
Deepser, the ITSM software, allows you to generate a working process, e.g. an approval process, using the Approvals module and the Flow module.
In this course, we are going to explain how to create an approval process using the Flow module in Deepser.
In Deepser, lists are organized data groups that can be used as options for custom, system fields and filter fields for grids.
By their nature, Lists always have a list of items marked by a unique “key” parameter in the list, but which could be repeated in other lists.
Lists are a useful tool for creating custom fields as they allow you to create options for them without the need to write code, which makes it easy to create custom fields even for users less accustomed to programming.
To create a new list, you will need to go to the menu: System-> Tools ->Lists.
At this point, you will need to click on the “Add List” button at the top right.
The following screen will then open:
Below are the fields with their associated description:
| Field | Description |
| Code | Unique code name of the list. |
| Name | Name of the list you are creating. |
| Compare List | This field is a system field, it can be ignored in the normal Deepser usage. |
| Compare List self-exclusion | This field is a system field, it can be ignored in the normal Deepser usage. |
| Image | Image associated with the list you are creating |
| Status | Status Of The List You Are Creating |
Once you have filled in the fields, you will need to click on “Save List” or on “Save And Continue Edit List”.
At this point, the list will have been created.
Suppose you want to create a list with name “Demo List” which will contain as different values possible versions of demos to be submitted to the customer. In particular, we will create an In Presence demo and a remote demo.
To do this, you will need to go to the menu: System -> Tools ->Lists.
At this point, we click on the “Add List” button.
Here we are going to fill in the “Code” field with the code of the list, this field by convention must be all lowercase and instead of spaces underscores must be used.
In our example, We will enter in the “Code”field” : “demo_types”.
Now we give a name to the list by filling in the “Name” field, in our example we will enter: “Demo Types
Now we leave all the other Default fields and click on the “Save List” or Save And Continue Edit List” button.
To create the actual elements that will become the options in a list-based select, we must go to the list in which we want to go to create the elements.
At this point, we go to the “Values ” tab and click on the “Add Value” button.
The following screen will then open:
In the Key field that indicates the unique key of the value, we are going to enter a number that must be different from those already present in the list. In our case, we enter 0.
Now, In the label field, we enter “Live Demo”.
After that we have to click the “Save List Value” button if we do not have to add other values or the “Save And New” button if we have to create others or the “Apply” button.
At this point you create in the same way a new entry called “Online Demo” with key set to 1.
Finally, on the main screen of the list, click on the “Save List” button to save the list.
At this point, the list will have been saved with the created items.
To configure a new Escalation rule in Deepser You will need to go to the System -> Service Configuration -> Escalation Rule menu.
Here, you will need to click on the “Add Rule” button.
Now the following screen will open:
Below are the fields and their meaning:
| Field | Description |
| Name | Name of the escalation rule |
| Model Alias | Model on which it will apply |
| Email Event | Associated email event that will be launched if the conditions of the rule are true |
| Level | Level, this field indicates what is the level of tickets that will have to be processed, by default it is 0 for all tickets |
| Next Level | The new level that the ticket will have after being processed by the rule |
| Cron Expression | Expression Cron, indicates how often this rule will be processed. |
| Status | Status of the rule, if “Enabled” the rule will be evaluated otherwise no. |
Note that the conditions to be specified for the rule will appear only after the rule has been saved at least once.
At this point, click on “Save” or “Apply” to save the rule.
At the end, the following screen will appear:
The new fields that will appear are the following:
| Field | Description |
| Escalate all Records with following values (Main Filter) | This query builder will be used to filter the tickets that will have to be processed In order to be evaluated , tickets must comply with the conditions of the query builder |
| Expression Input (Script) | This script field will be used to filter tickets that will have to be processed. In order to be processed, tickets must comply with the conditions of the script field (must return true). |
| Escalate all Records with following Timer values (applied after the Main Filter) | This query builder will be used to filter tickets that will have to be processed. In order to be processed, tickets must comply with the conditions of the query builder, in addition in this case the SLA metrics will also be evaluated as parameters of the query builder. |
| Expression Timer (Script) | This script field will be used to filter the tickets that will have to be processed . In order to be evaluated tickets must comply with the conditions of the script field in addition in this case the metrics of the SLA will be evaluated as parameters of the query builder. |
| Set Records values to | This query builder is used to set the values that have to be modified in the processed record. |
| Expression Output (Script) | This scripting field is used to set the values that have to be modified in the processed record. |
As a last step, after filling in the desired fields, you will need to click on the “Save” or “Apply” button to save the rule.
In Deepser you can access passwords in two ways, through the main menu, or, if properly configured, through the user portal.
1a – Access the Password module from the main Deepser menu.
1b – Access through the drop-down menu of the user portal.
2 – At this point you will see the grid with all the passwords that you are allowed to view
3 – To copy the address or username field, simply click the value of the line, to copy the password instead, click the icon with the two sheets, to display it click the eye icon.
Note: If you have the necessary permissions, the password quick change button will appear on the left of each line.
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.
1 – At first, start by choosing a name for the import procedure and the model of the entity to be created
2 – Then select the appropriate file extension, and if it contains an header, set “Header” to yes.
2b – if the file is a .CSV, configure the appropriate delimiters and enclosures (character used to end a line)
The field “Type” defines the file format.
It can be “CSV” or “XLS”.
These are the standard formats supported by Deepser.
As you can see in the example file attached below, each row will be treated as a single record to import, each column as single Model Field:
| CODE | NAME | TYPE | SUBTYPE | STATUS | ACTIVATION DATE | S/N | NOTES | OWNER COMPANY | ASSIGNED USER |
| 106545 | Apple Iphone XI | Mobiles | Smartphones | Active | 15/03/2019 | LFC6370742 | Scratches on the screen | INTODEEP srl | 4\euler |
| 106546 | Datapower 45 | Servers | Physical Server | Active | 20/12/2019 | LEV6267443 | INTODEEP srl | 4\riemann | |
| 106547 | Dell EM5000 | Computers | Workstations | Active | 5/04/2020 | LF96128119 | INTODEEP srl | 4\riemann | |
| 106548 | HP Pavilion 15S | Computers | Laptops | Active | 23/04/2020 | L8M6200959 | Noise coming from cooling fan | INTODEEP srl | 4\riemann |
Table1: example of an Excel File to import devices as CMDB Cis
3 – Remember to change the status to “enabled”, then click on the Upload button under “path label”.
4 – After the upload occurred, Deepser will recognise every field name in the document header, if present, the next step is the binding process.
In Deepser, you can configure an entity relationship.
To do this you will need to go to the menu: System->Relations.
In the screen that will open you will need to click on “Add Relation”.
At this point the following screen will open:
Below are the fields with their meaning:
| Field | Description |
| Source Model | Main model of the relation |
| Destination Model | The target (or related) model of the relation. |
| Status | Status of the relation. If “Enabled” then it will be visible and usable otherwise it will not be visible and usable. |
| Name | Relation name, from Destination to Source Model |
| Opposite Name | Inverse relation name, from Source to Destination Model |
| Source Id Field | Here we are setting which field must be used to identify the source model. For example, we can choose “entity_id”. |
| Source Label Fields | Here we are setting which fields we want to show up in the source relation grid. For example, we can choose “Name”. |
| Source Label Separator | Here we are setting the separator of the label fields in the source relation grid. |
| Source Search Field | Here we are setting which field must be used to search the source model. For example, we can choose “Name”. |
| Dest Id Field | Here we are setting which field must be used to identify the destination model. For example, we can choose “entity_id”. |
| Dest Label Fields | Here we are setting which fields we want to show up in the destination relation grid. For example, we can choose “Name”. |
| Dest Label Separator | Here we are setting the separator of the label fields in the destination relation grid. |
| Dest Search Field | Here we are setting which field must be used to search the destination model. For example, we can choose “Name”. |
In this guide, we are going to configure a relationship between an operation and the Ci.
To do this, you will need to go to the System -> Relations menu.
At this, we click the “Add Relation” button.
In the screen that will open, we will set the field “Source Model”: “DeepCmdb – Ci” and in the field “Destination Model”: “DeepService – Operation”.
In the “Name” field we will enter the name we want to give to the relation.
In the “Opposite Name” field we set the name for the opposite relation. For example, if we want to link an element of the CMDB to a ticket, we need to use the opposite relation.
Now, in the “Source” section we configure the “Source Id Field” field with the value “entity_id” and “Source Search Field” and “Source Label Field” field with “Name”.
Finally, in the “Destination” section we set the “Dest Id Field” field with the value “entity_id” and “Dest Search Field” and “Dest Label Field” field with “Title”.
As a last step, we must click on the “Save” or “Apply” button.
To create a relation grid, we need to create a custom field that will allow us to interact with the created relation.
To create the custom field, you need to go to System -> Custom Fields.
Here we will have to choose the model “DeepService – Operation”, in which we want to add the custom field.
Now we will have to go to the “Fields” section, here we will have to click on “Add field”.
The following screen will appear:
Inside “Column Name” field we set the field name we want to display. In this case “Relation Operation to CMDB “
In the “Column Type” field we set “Don’t Create DB Column”.
In the “Element Type” field we set “Relationgrid”, the type of element we want to create.
After these steps, in the “Relation” we select in the drop-down menu the relation that we have previously created.
Now you will have to click on the “Save” or “Apply” button.
Now, you can add this field called “Relation Operation to CMDB” to the form template of Operation.
For the configuration, see these article called “Form Template Configuration” and “Column Configuration“.
The Operation model contains all the necessary information for the management of the ticketing process. Every Operation, based on the Type field, can become, for example, a support request, an issue, a change request, etc.
Service operations are taken from the ITIL Methodology, where Service Operation is that part of service management that is concerned with ensuring that services are delivered effectively and efficiently. The lifecycle phase of Service Operation includes fulfilling user requests, resolving reported failures, troubleshooting problems, and performing routine operational activities.
Typically, Operations can be opened by End Users in the portal, and then managed by the internal support team, or by Operators, directly in the Deepser backend.
The first step to actively use the ITAM module, and then begin the automated introduction of Devices in Deepser, is the installation of the Agent.
The Agent is a lightweight Windows application that collects all available information regarding the device on which it is installed, and then systematically sending it to the server.
Once installed, the Agent can be converted in few simple steps into Remote Collector, so you can collect data by scanning the company network, or the subnet on which it is connected.
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 presents 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 on that has visibility and one in that does not have it, then the resource will be visible.
Metrics in Deepser represent the type of goal to be achieved: for example, responding to a ticket within a certain time, resolving a ticket in a certain time interval, or defining how much time should pass between first-level and second-level support.
In this lesson, we will discuss metrics in more detail.
The metrics in Deepser are the real counters that Deepser will use to manage and display the time of the Sla.
Deepser can handle numerous metrics, and the metrics will only start when the “Start” condition of the metric is evaluated as true, the metric is considered concluded only when the “Stop” condition.
To create a Custom metric, you will need to go to the menu: System->Service Design->Sla->Metric.
At this point, you will need to click on the “Add Metric” button.
At this point, the following screen will open:
Below are the fields with their Description:
| Name | Description |
| Name | The name of the Metric. |
| Model | Model on which this metric will be evaluated. |
| Status | Status Of The Metric, If Enabled” it will be evaluated otherwise it will not be evaluated. |
| Description | Description of the Metric. |
After configuring the fields, You can click on the “Save” button to save the metric.
Suppose you want to create a metric that is applied to the operation model, that starts counting the time when a ticket is in a new state and ends when the ticket is closed.
To create a Custom metric, you will need to go to the menu: System -> Service Design -> Sla -> Metric.
We create a new metric by clicking on “Add Metric”.
We set as “Name”: “Time to close”.
In the field “Model” we set “DeepService – Operation”.
In “Description” we can configure a description at our discretion.
At this point, the query builders “Start” and “Stop” will have appeared.
Now let’s configure the query builder “Start” as follows:
Now in the Stop query builder, we enter the following configuration:
At this point, we save the metric by clicking the “Save” or “Apply” button.
Note that before the metric becomes operational it will be necessary to define goals, we will see how to define the goals in the next lesson.
In Deepser, by default, images, embedded in the body of incoming emails, are saved as attachments to the email message and not included in the body and saved, for example, within the Description field.
Images can still be viewed from the Email List grid, in the operation form, in the Attachments column.
NOTE: By enabling this option the size of the Database can increase considerably over time, for this reason by default it is disabled.
To enable this option go to the system configuration menu: System->Configuration->General->Email->Attachment
Set ‘Embedded Images on Message Body‘ option to ‘Yes‘.
The User Menu of Deepser contains all the links to edit the user profile.
Below the icon with your avatar and name, clicking on the arrow, you can expand the menu:
The items of the menu are:
To limit as much as possible that end users open Tickets for questions/problems whose answers/solutions are already present in the Knowledge Base, in the Service Operations (Tickets) there is a standard Knowledge Base field.
This field, through a select, will propose the articles related to the scope of the ticket that is being created, if any.
The articles and the Knowledge Base to which they belong, to be proposed, must be visible by the current user and in the area in which it is located (User Portal or Guest Portal).
In this guide, we will see how to configure the form of the task type created in the previous lesson.
To start the form configuration, we must go to the menu System->tools->Task->Task Type.
Here we must select the typology created in the previous lesson.
At this point, we are going to enter in the “Form Expression” field the following code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | $this->addField( 'title', //unique identification name of the field. 'text', //type of the field array( 'label' => Deep::helper('deep_task')->__('Title'), //label of the field 'name' => 'title', //name of the label 'required' => true, // if the filed is required 'class' => 'required-entry', // css class for the field. ));$this->addField( 'description', //unique identification name of the field. 'textarea', //type of the field array( 'label' => Deep::helper('deep_task')->__('Description'), //label of the field 'name' => 'description', //name of the label 'required' => false, // if the filed is required 'autogrow' => true )); |
Now in the field “Form Portal Expression” we are going to enter the following code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | $this->addField( 'title', //unique identification name of the field. 'text', //type of the field array( 'label' => Deep::helper('deep_task')->__('Title'), //label of the field 'name' => 'title', //name of the label 'required' => true, // if the filed is required 'class' => 'required-entry', // css class for the field. ));$this->addField( 'description', //unique identification name of the field. 'textarea', //type of the field array( 'label' => Deep::helper('deep_task')->__('Description'), //label of the field 'name' => 'description', //name of the label 'required' => false, // if the filed is required 'autogrow' => true )); |
At this point, it will be possible to click on the “Save” or “Apply” button.
The result is shown below:
By definition, a workflow is the sequence of steps involved in moving from the beginning to the end of a working process.
The module that allows you to create a workflow is the “Flow Designer” module.
After opening your Deepser Backend portal, by clicking at “Flow” module and “Designer”
And the following screen will open:
The Flow Designer is where you can create a workflow.
In the upper section we can find the TRIGGER section which represents the starting point from which the approval process stars running.
In our example, your supervisor wants that an approval process starts when a ticket (or Operation) changes its status into “In Approval”. In this case, the trigger will be the change of the status.
In the below section, inside a red square, we can find the FLOW section which represents the approval process itself.
To build the FLOW section, located at the right, there are variables that can be dragged and dropped from right to left inside the trigger section and inside the flow section.
Therefore, it’s simple to choose visually which set of variables you need in order to create your process flow.
Located at the top right, there are
By clicking the button “Export”, the following screen will open:
By inserting an encryption key, you can export in a .txt file.
If you want to use the property “Import”, the button “Import” is shown in the main page of the Flow Designer Module (see the first image).
In the next article we are going to explain how to configure the TRIGGER section.
After the creation of a list with its list values, a question may have popped in your mind:
“How can I use the list values to filter other fields and pilot the autofill, for example, of a ticket?”
All you need is called “Model Visibility”.
Let’s create an example.
You will need to go to the menu: System-> Tools ->Lists and then click on the “Service Operation Status” list.
The following screen will then open:
Now let’s imagine we want to filter some Service Type based on a selected value from that list, for example the “New” value.
To do this, click on the “Add Model” button.
The following screen will then open:
| Field | Description |
| Model Alias | This field represent the name of the model in which you want to apply the filter. |
| Status | This field set the status enabled or disabled. |
| Expression with query builder | Using a query builder, it’s simple to set filters. From the drop-down select which field you want to filter and set the condition. |
| Expression (Script) | Use a custom code to set custom filters. |
In this way, we created a filter for the Status value “New” inside the Service Operation Model.
Inside the query builder we set that the Status value “New” can be displayed only for service Type equal to “Incident”.
Once you have filled in all the fields, you will need to click on the “Save” or “Apply” button.
Suppose you want to configure an escalation rule that gives high priority to all tickets whose requesting company is “Acme International”.
To do this, you will need to go to the System -> Service Configuration -> Escalation Rule menu.
Here, you will need to click on the “Add Rule” button.
Now the following screen will open:
At this point, we configure the “Name” field as “High Priority Acme International”.
We set the field “Model Alias” to “DeepService – Operation”.
Now, we configure the Level to zero and Next Level to1 fields, that is, this rule will process all tickets in zero state only once.
At this moment, we set the field “Cron Expression”: every 5 minutes using the drop-down menu located under the field itself.
As the last step of this first phase, click on “Save” or “Apply” to save the rule.
Now configure in the newly created rule the query builder “Escalate all Records with following values (Main Filter)” like this:
Now, let’s set in the newly created rule the query builder “Set Records values to” like this:
Finally, we can click on “Save” or “Apply”.
Deepser gives to each user the ability to store private passwords.
These passwords are defined as private , since they are only available to the user who created them, and even system admins don’t have access to them.
Private passwords are encrypted when set , and decrypted when read, using a passphrase defined at user level.
So to ensure greater security, each user can define their own passphrase.
In Deepser you can access passwords in two ways, through the main menu, or, if properly configured, through the user portal.
1a – Access the Password module from the main Deepser menu.
1b – Access through the drop-down menu of the user portal.
2 – Start the password creation procedure (see the dedicated guide in the academy), but set the Is private field to yes.
Note: It is possible to make a private password public, but not the other way around.
3 – A new button will appear, Reset user passphrase, this allows you to choose a passphrase at user level.
4 – After clicking the button, choose a personal passphrase, then save it.
5 – Now a personal passphrase is set, so you can proceed storing your private password by clicking Save.
Note: Not all view and use fields are present, because only the user who configured the private password can have access to it.
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.
Categories in Deepser are organized in a hierarchical tree structure of up to 3 levels.
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.
To make a category visible in the guest portal, you need to go to the menu: System -> Categories.
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.
This field is used to perform the binding (also called “mapping”) between each column of the source import file (Excel file) and the fields of the selected model in the Database, so that deepster can populate every field of its database with the correct corrisponding value.
Entity: this column has a list of fields from the entity inside the Database of Deepser. It is the list of fields (also custom fields) present in the DB table for the Model Selected. E.g.: if you select “DeepCmdb – Ci” Model, here you will find all the fields of the CIs in the Deepser database table deep_cmdb_ci.
File: it represents the column of the Excel import file, which is read. It is selected from a select-box containg the names of columns in the File header (first row of the Excel).
Code: by clicking the button in the code column, a scripting area will open. The PHP code in this area will be executed when the value of the single column selected is evaluated and saved.
1 – To define a new binding occurence, simply click the “+” button (light blue, below the fields list), to delete it, instead click on the red ‘minus’ button on the right side.
2 –Now you can bind each field(column name) from the source file to the corrisponding one in the Deepser entity model.
3 – Once the binding is completed, everything is set up for a basic import procedure, and you can start the process by saving and then clicking on the yellow ‘Run’button, or schedule the import to recur over time. If everything went well, a green label should state how many entities were affected.
In Deepser you can modify relationships using an event, as we will see in the following example.
This can be useful for creating relationship management flows including, for example, an approval phase.
In this example, we are going to create a flow for the management of the relation between users and the Ci class Location.
The objective of this report will be to keep records of which end users can access to the Ci class “Location”.
Suppose that a type of special service is created (Access Management), opening a ticket of this type users can ask to obtain access to a “Location”, once the request is sent, and it will be evaluated by the backend operators and if approved the relationship between the requesting user and the location will be mapped.
To create a new relation, we must go to the menu: System -> Relation.
Here we are going to click on the “Add Relation” button.
In the screen that will open, we will configure the “Source Model” field as “DeepCmdb – Ci”.
Now we will set the field “Destination Model” to “DeepAdmin – User”.
In the Source section, we are going to configure the field “Source Id Field” with the value “entity_id”.
In the “Source Label Fields” field and in the “Source Search Field” field, we will enter “Name”.
At this point in the “Destination” section, we will set the”Dest Id Field” field as “user_id”.
Finally, in the field “Dest Search Field” we set “username”.
As a last step, we are going to click on the “Save” or “Apply” button to save the relationship.
To create the custom field, you will need to go to System -> Custom Fields.
Here we will have to choose the model “DeepCmdb – CI”.
Now we will have to go to the item “Fields”, here we are going to click on “Add Field”.
At this point, the following screen will open:
We compile the fields as follows.
In the “Column Name” field, we are going to configure the value “cust_ci_user_relation”.
In the “Column Type” field, we are going to configure the value “Don’t Create DB Column”.
In the “Element Type” field, we are going to configure the value “Relationgrid”.
In the “Label” field, we are going to configure the value “Allowed Users”.
In the “Status” field, we are going to configure the value “Enabled”.
In the “Relation” field, we are going to select the name of the relationship created previously.
At this point, We must click on the “Save” or “Apply” button to save the field.
As a prerequisite for this step there is the configuration of a type of special service with related form templates on the user portal side, you can find the documentation about it at this link: link.
To create the custom event for the population of the relation, we must go to System -> Custom Fields.
Here we will have to choose the model “DeepService – Operation”.
Now we are going to configure a new custom event by going to the “Events” Tab and then clicking on the “Add Event” button.
Note that in this example we will use the “cust_ci_id” field (check the field names to fit your configuration, in case you do not use the default fields).
At this point, the following screen will open:
Here we are going to fill in the “Name” field with the name we want to give to the event and the “Type” field with the “After Save” value.
At the end of the field “Method” we enter the following code:
$operationType = 13;
$approvedOperationStatus = 8;
/**If this is setted and the type id is Access Managemt**/
if($this && $this->getData('type_id') == $operationType ){
/**Check if the request is approved**/
if($this->getStatus() == $approvedOperationStatus){
/**Load the Relation**/
$realtion = Deep::getModel('deep_relation/relation')->load(5);
/**Get Ci id**/
$ciId = $this->getData('cust_ci_id');
/**Load the requester user**/
$requester = $this->getRequesterUser();
/**If the CIid is set and the requester is not an empty object**/
if($ciId && $requester && $requester->getId()){
/**Adding The requester user in relation with the ci**/
$realtion->addRoles($requester->getId(),[$ciId]);
}
}
}
As a last step, you will need to click on the “Save” or “Apply” button to save the event.
This guide covers all the basic steps required to create a new Operation.
1 – The creation of a new Service Operation can be done from the portal, or from the Backend (accessible only by operators).
1a – From the User Portal, select the type of request you intend to open.
1b – From the menu present in the Backend, access the grid of the type of service concerned (in the example you want to create a Generic Request).
Note: By default, Deepser implements Incident, Request, Problem, Change service types, but each environment can be configured with custom Service Types.
2 – From Backend, press the Add Operation button (the name ‘Operation‘ varies according to the name of the service type involved).
3 – If the Operation has been created through the User Portal (End Users do not have access to the Backend), then a different Form Template will be loaded.
The standard Form Template from the User Portal looks like this:
The meaning of the fields available by default is the following:
| Field | Meaning |
| Title | The title of the Operation. Usually a brief description. |
| Category | The Operation category. It is a fundamental piece of information for managing the assignment to the workgroups and for cataloguing the scope of the required activity in a precise manner. |
| Urgency | The Urgency indicated by the user of the Operation |
| Description | The detailed description of the ticket, with any additional information. |
3a – Fill in all relevant fields, then press Save to save the Operation and close the insertion template, or press Apply to save but stay on the page. Pressing Reset will cause the values to be restored to the last saved version.
Note: The figure represents the template displayed by default when opening the request on the backend side.
4 – After saving, the operation will be visible within the user portal.
4a – Or it will be visible on the backend side within the selected Service Type.
5 – The Delete button allows the physical deletion of the ticket*, while Close causes it to be closed (Status = Closed). Print Report activates the generation of a ticket report.
Each Operation can be deleted. This happens if you set the Operation in a state of class “Deleted”. Requests deleted in this way are not physically elminated from the DataBase, but are only logically elminated (they will be visible in the Deleted grid). To physically delete a request from the DataBase, use the Delete button. This button permanently deletes the record from the system, which will no longer be recoverable.
To install the Agent go to the Deepser back-end, from the menu access the Asset>Device section, click on the “Download Agent” button at the top right (as shown in figure).
The installer will be downloaded.
All the information necessary to configure communication with the Server (URL, port) is contained in the name of the executable.
Run the installer (requires Administrator privileges) and, if necessary, modify the pre-filled connection parameters; finally click on the install button to start the installation.
Once the installation is complete, on the device desktop, an icon named ‘Portal’ and a new start menu entry named ‘DeepAgent’ menu will appear.
By clicking on the ‘Portal’ icon you will be redirected to the opening page of a new Ticket where the device in use will be automatically set in it. The proposed type of Ticket created through the Agent can be changed in the Portal configuration section.
To ensure installation has taken place correctly and there are no communication problems, go to the Device section of the Asset module from the Deepser back-end menu (Asset>Device).
In this section, the record representing the device on which the Agent has been installed will be displayed.
To access the Agent user interface, click on the ‘DeepAgent’ entry added to the Start Menu.
In the first tile, the one with an icon representing an “eye”, you can check the status of the ‘DeepAgent’ service.
In the second tile, the one with an icon that represents a “wifi” network connection, there is the interface for converting an Agent into a Remote Collector (the conversion process will be discussed in the dedicated section).
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.
The goals in Deepser are the objectives that the metrics must achieve.
More than one goal can be taken for the same metric depending on the parameters needed. In this lesson we will see more in detail the goals in deeloser.
The goals in Deepser are metric’s objective, they allow you to define by when a certain metric must be concluded.
For each metric, multiple goals can be defined depending on the customer, the priority of the ticket or any other necessary field.
To create a custom goal, you will need to go to the menu: System -> Service Design -> Sla -> Metric.
Click on the metric on which we want to apply this Goal.
Once you have opened the metric screen to add a goal, you will need to click on the “+” button in the “Goal” section.
At this point, the following screen will open:
Below are the fields with their Meaning:
| Name | Description |
| Name | Name we will give to the goal |
| Calendar | The calendar on which this goal will be set, normally the default calendar is used, however any of the available calendars can be selected. |
| Target | Time within which this goal must be executed. |
| Position | Position in the list of goals (in case there is more than one this field indicates in which order we want to display it). |
| Expression | Query Builder that allows you to define a condition for which this goal will be applied for example we can have a specific goal that will apply for a single company. |
At this point once you have filled in the fields you will need to click on the “Save” button to save the goal and click on the “Save” button also of the metric to save the updated metric.
To create a custom goal, you will need to go to the menu: System -> Service Design -> Sla -> Metric.
Click on the metric on which we want to apply this Goal.
Once the metric screen opens, to add a goal, you will need to click on the “+” button in the “Goal” section.
At this point the following screen will open:
In the “Name” field we set “Goal Acme Intenational”.
In the Calendar field we set the calendar created in the previous lessons, in this case “Demo Calendar”.
In the “Target” field we set 1 hour.
The position field can be left blank, in this way the position will be determined automatically according to their ids.
In the “Expression” field we set:
At this point once you have filled in the fields you will need to click on the “Save” button to save the goal and click on the “Save” button also of the metric to save the updated metric.
Using Mailboxes, Deepser can Receive and Process Emails, send Notifications, etc.
There are no limits about the number of email addresses that can be integrated, nor on the provider.
The Navigation Menu of Deepser contains the main links to the modules that compose the software.
Using this menu it is possible to access all the screens of the main functions of the software back-end portal.
The Navigation Menu has 2 main sections:
The Navigation Menu is different from user to user, based on the user permissions:
The items in the Navigation Menu can contain sub-menus. In this case Deepser adds an icon on the lower corner of the menu item:
By clicking on the item with that icon we can expand the sub-menu, with other items, eventually expandable themselves:
If we select an item with no sub-menu the Main Screen of Deepser will be redirected to the main screen of the chosen module.
To make the use of the tool faster, it is possible to hide the Navigation Menu and to expand the main screen.
To hide the navigation menu click on the blue button near the global search textbox.
You can add or modify an existing article both from the Deepser backend (for operators) and from the User Portal.
1 – After clicking on the View button of a Knowledge Base, if you have the necessary privileges you can:
1b – By pressing the pencil icon you can then edit an article
2 – At this point you will see the form for creating/editing an article.
The form fields have the following meaning:
| Field | Description |
| Title | Title of Article |
| Identifier | Identification code of the article. It will be used in the composition of the article URL if it and the KB to which it belongs have been made visible in the Guest Portal. |
| Category | Category. You can use it to configure suggestions to KB articles from a Service Operation (ticket). |
| Visibility in Frontend | If set to YES, then the article will be visible and searchable by unauthenticated users in the Deepser Guest Portal. |
| Visibility in the Portal | If set to YES, then the article will be visible and searchable by authenticated users in the Deepser User Portal. |
| Visibility Administrators | If set to YES, then the article will be visible and searchable by operators from the Deepser backend. |
| Comments Enabled | Allow comments to an article. |
| Tags | Tags of the article. By default it is through tags that KB articles are offered in Service Operations. |
| Description | Body of the article. |
The global task grid is a configurable grid that allows you to view all the tasks that have been created in the system. 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 items and the Work Activity item.
By clicking Task 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 relative task is contained is opened (for example, the ticket in which the task is contained). |
| Id | The numeric and unique id that identifies the task. |
| Status | The status of the task. |
| Type | Type of task. |
| Model Alias | The template that contains the task. |
| Owner User | The user who owns the Task. By default it coincides with the user who created it. |
| Assigned User | The user who is assigned to perform the task. |
| Assigned Group | The group that is assigned to perform the task. |
| Portal Visibility | Visibility of activity in the front-end. By default, tasks are not shown in the user portal. |
| Started At | The date that indicates the start of the activity. |
| Ended At | The date indicating the end of the activity. |
| Created by | The user who created the task. |
| Created at | The date and time that indicates the creation of the task. |
The global task grid has preset visibility. In fact, a Key User or Agent user who accesses the grid will have visibility only in tasks that fall within at least one of the following cases:
A user with an Admin role, on the other hand, will have visibility of all the tasks without any preset filter.
In this article we are going to analyze the Flow Trigger block.
The “Trigger” block is the only existing building block in all flows.
It is essential for the configuration of flows as it determines under what conditions a flow will have to be executed.
In the flow form, the trigger field can be configured to perform the associated flow in the following ways:
Below we will analyze the possible macro configurations for the trigger field:
If the trigger block is configured in Model – Created, the associated flow will be executed when a Deepser entity, specified in the “Model” field as in the figure below, is created (e.g., when creating a ticket).
It will also be possible to define more specific conditions for the entity that will be created in order to perform the associated flow.
For example, let’s say we want to perform a flow when creating an “incident” type ticket, to do so we will have to configure the field in this way:
At this point you will need to click the Save button in the “Trigger” block to save the block itself.
If the trigger block is configured in Model – Updated, the associated flow will be executed when a Deepser entity, specified in the “Model” field as in the figure below, is modified.
It will also be possible to define more specific conditions for the entity that will have to be modified in order to perform the associated flow.
It will also be possible to define whether the flow associated with the trigger should be executed only once or more using the “Run Trigger” field:
Below is a list of the values that this field can take on and their meaning:
For example, let’s say we want to perform a flow when modifying an “incident” type ticket, to do so we will have to configure the field in this way:
At this point you will need to click the Save button in the “Trigger” block to save the block itself.
If configured in Model – Created or Updated trigger, the associated flow will be executed when a Deepser entity, specified in the “Model” field as in the figure below, is created or modified.
It will also be possible to define more specific conditions for the entity that will have to be modified in order to perform the associated flow.
It will also be possible to define whether the flow associated with the trigger should be executed only once or more using the “Run Trigger” field:
Below is a list of the values that this field can take on and their meaning:
For example, let’s say we want to perform a flow when creating or modifying an “incident” type ticket, to do so we will have to configure the field in this way:
At this point you will need to click the Save button in the “Trigger” block to save the block itself.
If configured in Model – Deleted trigger, the associated flow will be executed when a Deepser entity, specified in the “Model” field as in the figure below, is deleted.
It will also be possible to define more specific conditions for the entity that will have to be modified in order to perform the associated flow.
Below is a list of the values that this field can take on and their meaning:
For example, let’s say we want to perform a flow when eliminating an “incident” type ticket, to do so we will have to configure the field in this way:
At this point you will need to click the Save button in the “Trigger” block to save the block itself.
If the trigger is configured in Cron, the associated flow will be executed at a time interval established by the cron expression.
For example, let’s say we want to run a flow every 5 minutes, to do so we will have to configure the field like this:
At this point, you will need to click the Save button in the “Trigger” block to save the block itself.
After the creation of a list with its list values and a model visibility, another question may have popped in your mind:
“How can I set the same list value inside different models, for example the Service Module and the CMDB Module?”
“How can I use list as a data source?”
To use a list as a data source of a custom field, you will need to go to the menu:
System -> Custom Fields.
Here, we will select the template on which to create or modify the custom field in question.
In our case, it will be the “DeepService – Operation” model.
Once we have clicked on the model we want to modify, we go to the “Custom Fields” section, here we will send you to click on the “Add Field” button.
The following screen will then open:
We configure the “Column Name” field as demo_types.
We configure the “Name “field as “Demo Types”.
“Column Type” we set it to “integer”.
Instead, we set “Element Type” to List.
At this point in the field that will have appeared “List Code” select the list created in the previous point.
Finally, we set the field “status” to “Enabled”.
In the end, click on the “Save Field” button or on the “Apply” button.
After all, the field will have been created.
By entering the field in a form template, you will now notice that the values of the field will correspond to those of the list.
To add the field from a formtemplate you can refer to the guide on form templates which can be accessed by clicking here.
In Deepser, Escalation rules can trigger email notifications. This allows you to use escalation rules to eliminate alerts when specific events occur. In the following example, we are going to create an escalation rule that will notify the user in case the requesting company is Acme International. In this example, we will also use the escalation rule created in the previous example.
In order to send the email notification to the assignee user, it will be necessary to create an email event with its associated mail template that will be used by Deepser to send the email from the escalation rule. To create a custom, you will need to go to the System -> Tools -> Email -> Template menu. Then you will need to click on the”Add Mail Template” 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 – New ticket from Acme International')?>
Now, it will be possible to insert in the “Body” section, which will represent the content of the message, the PHP / HTML code that will be used to generate the body of the mail.
You can use the following code as a reference when creating the body:
<?php
$requesterUser = $this->getModel()->getRequesterUser();
$assignedUser = $this->getModel()->getAssignedUser();
?>
<?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″ bor-der=”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’, $this->getModel()->getAssignedUser()->getDisplayUsername())?>,<br>
<?php $url = $this->getModel()->getAssignedUser()->isUser() ? $this->getModel()->getPortalUrl() : $this->getModel()->getUrl(); ?>
<?php echo Deep::helper(‘deep_email’)->__(‘You have Re-cived a new ticket from Acme International’)?> <b style=”font-weight: 700;”><a href=”<?php echo $url ?>”><?php echo $this->getModel()->getId()?></a></b>
<br>
<br>
<strong><?php echo Deep::helper(‘deep_email’)->__(‘Title’)?></strong>:
<br><?php echo $this->getModel()->getTitle()?><br><br>
<strong><?php echo Deep::helper(‘deep_email’)->__(‘Description’)?></strong>:
<br><?php echo $this->getModel()->getDescription()?><br>
<!– Status –>
<?php if($this->getModel()->getStatus()):?>
<strong><?php echo Deep::helper(‘deep_email’)->__(‘Status’)?></strong>:
<?php
$statusList = Deep::helper(‘deep_list’)->loadList(Deep_Service_Model_Operation::LIST_CODE_STATUS);
$statusValue = $statusList->getValue($this->getModel()->getStatus());
?>
<br><?php echo Deep::helper(‘deep_email’)->__($statusValue->getValueLabel()); ?><br><br>
<?php endif;?>
<!– Requester –>
<?php if($requesterUser && $requesterUser->getId()):?>
<strong><?php echo Deep::helper(‘deep_service’)->__(‘Requester User’)?></strong>:
<?php if($this->getModel()->getRequesterUser()->getAvatar()):?>
<br><img src=”<?php echo $this->getModel()->getRequesterUser()->getAvatarUrl() ?>” border=”0″ style=”-ms-interpolation-mode: bicubic;” width=”16″ />
<?php endif;?>
<?php echo $this->getModel()->getRequesterUser()->getDisplayUsername() ?><br><br>
<?php endif;?>
<!– Assigned –>
<?php if($assignedUser && $assignedUser->getId()):?>
<strong><?php echo Deep::helper(‘deep_service’)->__(‘Assigned User’)?></strong>:
<?php if($this->getModel()->getAssignedUser()->getAvatar()):?>
<br><img src=”<?php echo $this->getModel()->getAssignedUser()->getAvatarUrl() ?>” border=”0″ style=”-ms-interpolation-mode: bicubic;” width=”16″ />
<?php endif;?>
<?php echo $this->getModel()->getAssignedUser()->getDisplayUsername() ?><br><br>
<?php endif;?>
<!– Urgency –>
<?php if($this->getModel()->getUrgencyId()):?>
<strong><?php echo Deep::helper(‘deep_email’)->__(‘Urgency’)?></strong>:
<?php
$urgencyList = Deep::helper(‘deep_list’)->loadList(Deep_Service_Model_Operation::LIST_CODE_URGENCY);
$urgencyValue = $urgencyList->getValue($this->getModel()->getUrgencyId());
?>
<br><?php echo Deep::helper(‘deep_email’)->__($urgencyValue->getValueLabel()); ?><br><br>
<?php endif;?>
<!– Priority –>
<?php if($this->getModel()->getPriorityId()):?>
<strong><?php echo Deep::helper(‘deep_email’)->__(‘Priority’)?></strong>:
<?php
$priorityList = Deep::helper(‘deep_list’)->loadList(Deep_Service_Model_Operation::LIST_CODE_PRIORITY);
$priorityValue = $priorityList->getValue($this->getModel()->getPriorityId());
?>
<br><?php echo Deep::helper(‘deep_email’)->__($priorityValue->getValueLabel()); ?><br><br>
<?php endif;?>
<!– Solution –>
<?php if($this->getModel()->getSolution()):?>
<strong><?php echo Deep::helper(‘deep_email’)->__(‘Solution’)?></strong>:
<br><?php echo $this->getModel()->getSolution()?>
<br>
<?php endif;?>
</p>
</td>
<td class=”w22″ width=”41″ style=”font-size:1px; line-height:1px;”> </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 –>
<!– End of Main Content –>
<?php $url = $this->getModel()->getUrlByUser($assignedUser); ?>
<!– 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″ bor-der=”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’)->__(‘Go to the Ticket’)?>
</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. At this moment, it will be necessary to give a name to the event by filling in the “Name” field. We define Whether to send attachments by changing the value of the field”Send Attachments” 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 “DeepService – Operation” in the “Model” field In the “Event Expression”entry. We insert the following code:
// if the Company is Acme International
if($this->getModel()->getData("requester_company_id") == Deep::getModel("deep_company/company")->load("ACME International",'name')->getId() ){
if ($this->getModel()->getData('escalation_rule')){
return true;
}
}
return false;
In the “To” section We insert the following code:
$user = $this->getModel()->getAssignedUser();
if ($user && $user->getId()){
$this->changeLanguage($user->getLocale());
$this->addTo($user->getEmail());
}
At this point, we can go to click the “Save” or “Apply” button Now the event will have been saved
To assign the mail event to the escalation rule you will need to go to the menu: System -> Service Configuration. Here you will need to go to the previously created rule or any escalation rule you want to change. In the Escalation Rule screen you will need to select the Created event from the drop-down menu that will appear by clicking the “Email Event” field. At this point you will need to click the “Save” or”Apply” button.
In this example, suppose you want to email the administrator when the number of hours remaining in a contract line is less than 4
In order to send the email notification to the administrator, it will be necessary to create an email event with its associated mail template that will be used by Deepser to send the email from the escalation rule. To create a custom mail event, you will need to go to the System -> Tools -> Email -> Template menu. Then you will need to click on the”Add Mail Template” 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 $line = $this->getModel()?>
The contract line <?php echo $line->getLineNumber() . ' - ' . $line->getName()?> of the contract <?php echo $line->loadContract()->getContractNumber() . ' - ' . $line->loadContract()->getName()?> is going low
Now it will be possible to insert in the “Body” section, which will represent the content of the message, the PHP / HTML code that will be used to generate the body of the mail. You can use the following code as a reference when creating the body:
<?php $this->includeTemplate("header") ?>
<style>
.table{
width: 100%;
margin-left:auto;
margin-right: auto;
}
.tr,.td{
width: 100%;text-align: center;
vertical-align: middle;
}
.cust-container{
display: flex;
justify-content: center;
margin-left: auto;
margin-right: auto;
}
</style>
<!-- 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>
<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>
<div class="cust-container">
<?php $residuo = sprintf("%02d:%02d", floor($line->getRemainingTime()/3600), floor(($line->getRemainingTime()/60) %60))?>
The Contract Line <b><?php echo $line->getLineNumber() . ' - ' . $line->getName()?> </b> <?php echo " is going low ({$residuo} Hours remaning ) ";?>
</div>
<br>
<br>
<table class="table">
<tr class="tr">
<td>
<strong><?php echo Deep::helper('deep_email')->__('Total Time')?></strong>:
<br><?php echo sprintf("%02d:%02d", floor($line->getTotalTime()/3600), floor(($line->getTotalTime()/60) %60))?><br><br>
</td>
<td>
<strong><?php echo Deep::helper('deep_email')->__('Remaining Time')?></strong>:
<br><?php echo sprintf("%02d:%02d", floor($line->getRemainingTime()/3600), floor(($line->getRemainingTime()/60) %60))?><br><br>
</td>
</tr>
<tr class="tr">
<td>
<strong><?php echo Deep::helper('deep_email')->__('Name')?></strong>:
<br><?php echo $contract->getName()?><br><br>
</td>
<td>
<strong><?php echo Deep::helper('deep_email')->__('Customer Company')?></strong>:
<br><?php echo $company && $company->getId() ? $company->getName() : ''?><br><br>
</td>
</tr>
</table>
</p>
</td>
<td class="w22" width="41" style="font-size:1px; line-height:1px;"> </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 -->
<?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. 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 by changing the value of the field”Send Attachments” 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 “DeepService – Operation”in the “Model” field In the “Event Expression”entry. We insert the following code:
if ($this->getModel()->getData('escalation_rule')){
return true;
}
return false;
In the “To” section We insert the following code:
$adminUserToNotify = 'admin';
$admin = Deep::getModel('deep_admin/user')->loadByUsername($adminUserToNotify);
if($admin && $admin->getId()){
$adminEmail = $admin->getEmail();
if($adminEmail){
$this->changeLanguage($admin->getLocale());
$this->addTo($adminEmail);
}
}
At this point, we can go to click the “Save” or”Apply” button Now the event will have been saved
To assign the mail event to the escalation rule you will need to go to the menu: System -> Service Configuration. Here you will need to go to the previously created rule or any escalation rule you want to change. In the Escalation Rule screen, you will need to select the Created event from the drop-down menu that will appear by clicking the “Email Event” field. At this point, We are going to configure the “Level” field to 0 and the “Next Level” field to 1. Since we do not want to receive the notification every time the rule runs, but only the first time. Finally we are going to configure the field “Cron Expression”at 5 minutes using the drop-down menu located below the field itself. In the “Escalate all Records with following values (Main Filter)” field.At this point, you will need to click the “Save” or “Apply” button.
To guarantee the confidentiality of saved public passwords, Deepser encrypts them before saving them into the database, using a key defined by the Admin, called Passphrase.
Before defining any password, you must enter a passphrase, otherwise an error message will be generated. To do this, simply go to System Configuration-> Password-> Configurations
This is the system configuration screen for passwords.
The meaning of the fields is as follows
| FIELD | Example / Notes |
| Passphrase | The key with which passwords will be encrypted and decrypted. |
| Password Timeout in Seconds | Time in seconds that defines when the user in the password page will be logged out. |
| Minimum Password Length | Indicates the minimum length of the passwords (the minimum assignable is 3 anyway). |
| Default Password View/Edit Groups | Indicates the group that will have read/edit acces to the password by default, if no group was specified when creating the password. |
| Default Password View/Edit Users | Indicates the user who will be given access to read and change the password by default, if no user was specified when creating the password. |
| Enable Private Password | Gives users the ability to create private passwords. |
| Enable Private Password Groups | Indicates which groups of users can save private passwords. |
Once the passphrase is configured, you can configure the minimum length of the password and, for security reasons, the time after which any user on the password page is logged out. This allows you to prevent malicious users from accessing passwords, in case a user has accidentally forgotten the computer logged in on the passwords screen. After the time elapsed , Deepser will automatically logout the user from the web application.
Deepser, through the fields Default Password View/Edit Groups and Default Password View/Edit Users allows to establish a default behavior, in case no user or group is indicated as viewer or editor, in the password creation form.
Deepser allows users to save private passwords that are not accessible or editable by any user except the creator.
These passwords can become public, but the opposite is not possible. Enable Private Password to ‘Yes’ also allows end users to create passwords through the portal, all passwords entered through the user portal are private.
Note: You may need to make the Is Private field visible in the password creation template form to do this by editing the template using the edit button.
Finally, drag and drop the field and save.
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.
Sometimes there’s the need to import files with complex data types, or to avoid creating duplicates, etc., for all these needs the code section is essential, there are 4 main coding section, plus one for each entity field.
The scripting area “Before Run” is were to put Custom PHP code that has to be executed before import procedure starts.
It is commonly used to retrieve records from the DataBase and to put those records inside an Array, in order to avoid multiple select queries on the DB.
Typically, data retrieved are the same model of the import. But we can use this scripting area also to pre-load related models. For example, if we are importing CMDB CI records, we could pre-load a collection of CMDB Types and CMDB Subtypes inside this scripting areas.
The collections are typically stored inside variables, that are available also inside the other scripting areas.
Attention: if you use the same name of a PHP variable, it will be overwritten.
In Deepser, you can define an inverse relationship with respect to the parent relationship.
This allows you to trace back from the entity related to the main one.
Taking as an example the report addressed in the previous point of this guide, using the Reverse Relationship it will be possible to connect from the user to all the Cis to which he has access.
In this example, we will see how to configure the relationship seen in the previous point of this guide to be able to trace from the user to all the Location class ci to which it has access.
To do this, you will need to go to System -> Custom Fields.
Here we will have to choose the “DeepAdmin – User” template.
Now we will have to go to the “Fields” item, here we are going to click on “Add Field”.
At this point, the following screen will open:
We compile the fields as follows:
As a last step, we must go to the “Extras” tab and configure the “Opposite” field on Yes.
At this point, We must click on the “Save” or “Apply” button to save the field.
Now it will be sufficient to add the field in the template form of the users, and we will be able to view and interact with the inverse relation.
This guide will cover other standard actions in Operations, such as inserting a comment, a WorkLog, attaching a file or adding a Task.
1 – The access to the Service Operation can be made from portal, or from Backend (exclusive access to operators).
1a – Select the Affected Operation within the Users portal.
1b – Or select the Operation through the Deepser Backend.
2 – This guide uses as an example the insertion of elements in the operation from the Users portal, to get an overview of how this looks in the Backend, please refer to the Admin section of this Academy.
To enter a comment, scroll down to the Comments tab, and click on Add Comment
Note: To explore this topic further, please see the dedicated section in the academy.
To enter a work activity, scroll down to the Comments tab, and click on the Work Activity tab, then on Add Activity.
Note: To explore this topic further, please see the dedicated section in the academy.
To attach a File, scroll down to the Comments tab, and click on Upload a file, or drag and drop the file into the Drag and Drop area.
Note: To explore this topic further, please see the dedicated section in the academy.
To add a task, scroll down to the Comments tab, and click on Task.
Note: To explore this topic further, please see the dedicated section in the academy.
The first step for collecting information in Agent-less mode is to configure a Remote Collector, a small-sized Windows application, which allows you to:
It is recommended to install the Remote Collector on a Windows computer that can communicate through the network with as much devices as possible, in order to reduce the number of Remote Collectors needed.
It is possible to configure more than one, this is necessary for particular corporate network configurations, for example, if the network is organized in subnets isolated among them.
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.
Mailboxes are one of the fundamental entities in email integration.
In order to send emails to your users, in fact, you need to define an outgoing mailbox, in this guide we are going to explain the procedure for its setup.
To configure a mailbox in Deepser, in the backend navigation menu, navigate to the System->Tools->Email->Mailbox section.
The grid in this section shows mailboxes already configured in Deepser.
To configure a new mailbox click on the ‘+ Add Mailbox‘ button in the top right corner.
At this point the mailbox configuration form will open.
Once the mailbox type has been set, in this case ‘OUT‘, all fields for the outgoing mailbox configuration will be loaded dynamically.
The fields in the form have the following meaning:
| TAB | FIELD | MEANING |
| GENERAL DATA | Name | Name of the mailbox. It is a descriptive field used in the system to display the mailbox. |
| Type | IN or OUT (IN to receive emails, OUT to send emails). | |
| Status | If “Disabled” the email integrations will not be active. | |
| Email Display | The displayed email address. It is not the username. The username is used to access the email, this field is only the displayed email address if our server allows us to use a different email address for the outgoing messages. | |
| Display Name | The name displayed in the “From” field of the emails (eg: Your Service Desk). | |
| Host | The address of the mailserver. It depends on your provider or mailserver. | |
| Door | Port for the connection to the mailserver. | |
| Encryption | Encryption of the connection to the mailserver. It depends on your provider or mailserver. | |
| User Name | User name (usually the email address) to connect to our mailbox. | |
| Password | Password to connect to our mailbox. | |
| Protocol | Protocol to send emails (SMTP or OWA). It depends on your provider or mailserver. | |
| OAuth Client | OAuth2 client used for the authentication on services that require it. | |
| SITEMA DATA | Prefix | It’s the prefix to prepend to the unique field of the record (usually the ID) sent by email. The Prefix is mainly used in the Subject of the email by the incoming integration (mailbox IN), to tell Deepser if it has to create a new record or to update an existing one. To give an example, if we are sendind an email for a Service Operation record, we can define that the prefix is “TICKET#”. By doing so, the emails will be sent with the subject “TICKET#ID” (where ID is the unique number of the Service Operation). If the user answers that email must not delete this text, to make Deepser aware of the record the email is referring to. |
| Allowed Emails | It tells if emails can be sent only to users registerd in the system or to any email address. | |
| Is Default Outgoing | It tells if the email is the default to send notifications. Deepser lets configure an infinite number of mailboxes, but the system needs to know which is the default one to send notifications. Every Service Operation record, for example, contains a field called Mailbox ID, that represents the email address to send the notifications for that record. If this field is not filled, then the emails will be sent using the Default Mailbox. | |
| Exclude Expression | In this field you can insert a regular expression in order to block emails whose recipients match the defined expression. | |
| ADVANCED | Custom Code | Custom PHP code executed after an email has been sent. It is possible to configure this field to trigger custom events. For example, if we wanted to update a counter of the reinders or update a specific entity of Deepser, we could exploit the customization of this field. |
Once the form has been filled and the configuration saved, click on the ‘Check‘ button, top right, to test the configuration.
If the mailbox has been configured correctly you will see a message of successful connection, otherwise an error message.
The Global Search Bar lets you easily find all records in the system: for example and Activity, a Support Request, a User, a Customer, a File Attachment, etc.
The Global Search textbox compares the text in it with the unique ID and the name of the entity and returns a list of all possible matches (if the record doesn’t have a Name field then another identification field is compared, for example a file name of an attachment or a title of an appointment).
Near the Global Search Bar, the blue button lets you hide the Navigation Menu, expanding the Main Screen.
The creation of Knowledge Base is only allowed to System Administrators, while the ability to create or modify articles of the Knowledge Base can be granted to other categories of users through the corresponding configuration form of the KB itself.
1 – To create or configure a Knowledge Base you need to access the System à Knowledge Base section from the Deepser backend.
In the next screen click on the button at the top right
2 – The form for creating/modifying a Knowledge Base will then be shown.
The form fields have the following meaning:
| Camp | Significance |
| Name | Name of Knowledge Base |
| Icon | Possible Knowledge Base icon |
| Identifier | KB identification code. It will be used in the composition of the KB URL if it has been made visible in the Guest Portal. |
| Description | Description of the KB. It is displayed when a KB is opened before an Article is consulted. |
| Brief description | Brief description. It is displayed in the grid of the Knowledge Base section, that is the screen in which the KB are shown. |
| Location | Location of the current KB inside the screen, organized as a grid, where the KB are displayed. |
| Columns | Number of columns occupied by the KB in the KB selection grid to consult. |
| State | State. If the status is enabled, the KB will be visible and searchable. |
| Visibility Administrators | If set to YES, then the KB will be visible and searchable by operators from the Deepser backend. |
| Visibility in the Portal | If set to YES, then the KB will be visible and searchable by authenticated users in the Deepser User Portal. |
| Visibility in Frontend | If set to YES, then the KB will be visible and searchable by unauthenticated users in the Deepser Guest Portal. |
| Groups View Kb | In this field are inserted the groups to which give visibility of the KB. |
| Groups Edit Kb | In this field are inserted the groups to which to grant the possibility to modify the KB (es: creation/elimination of articles). |
In Deepser it is possible to configure the way in which the search between the various articles is carried out, allowing to obtain better results. Various filter types are used to do this.
You can access the global grid configuration for 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 tasks that must be retrieved and shown in the grid through the appropriate Query Builder.
For example, you can view only the tasks that have been placed within the tickets by setting the following control in the Query Builder: Model equal DeepService – Operation.
Through the special checkbox Massive Actions, you can activate the massive actions in the grid.
Massive actions allow you to modify one or more tasks through a grid selection. The massive action that is currently implemented by default is that of elimination.
Please Note: Elimination through massive action will result in a physical deletion to the database. Deleted 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 tasks and a button to export them.
Through the export will be extracted in the desired format the data of the tasks that are shown in the grid.
At the export click you will be shown a popup that will ask if you want to export only the tasks visible at the time of export or whether to export all the tasks.
A question may have popped in your mind:
“How can I create a workflow that is divided into several steps?”
If you want to create a workflow divided into various steps, another important module is the “Stage Set” module.
After opening your Deepser Backend portal, by clicking at “Flow” module and “Stage Set” module
And the following screen will open:
By clicking the button “Add Template”, located at the left in the middle of the form template, the following screen will open:
Here is where you can create each step in which you want to divide your process flow.
The Template structure contains fields that express:
| Name | Description | Note |
| Name | represent the name of the stage | for example “In Approval”. |
| Labels | represents the status that can occur during the execution of the stage process. | -The status called “Completed”, which means that the stage “In Approval” has been completed. -The second status is called “Skipped”, which means that the stage “In Approval” has been skipped, and so on. |
| Duration | represent the temporal reference for each stage |
The final oucome will be:
In the next article we are going to explain how to view the flow execution.
In Deepser, you can configure an escalation rule based on a metric.
This allows you to perform actions in Deepser for example when a ticket is not assigned after a certain time from its creation.
For this example, suppose we have a “Time to Respond” metric already configured, it will have as a start condition that the ticket status is “New”, and as a Stop condition that the state is any other state that is not “New”.
To configure a new escalation rule, you will need to go to the System -> Service Configuration -> Escalation Rule menu.
Here you will need to click on the “Add Rule” button.
Now the following screen will open:
At this point we configure the “Name” field as “Set priority high for non-assigned ticket after 1 hour”.
We set the field “Model Alias” to “DeepService – Operation”.
Now we configure the Level to zero and Next Level field to one, that is, this rule will process all the tickets in zero state and also update the Level to avoid double processing entity.
At this moment, we set the field “Cron Expression” Every 5 minutes using the drop-down menu located below the field itself.
As the last step of this first phase, click on “Save” or “Apply” to save the rule.
Now configure in the newly created rule the query builder “Escalate all Records with following Timer values (applied after the Main Filter)” like this:
At this point, we have to configure the query builder “Set Records values to” like this:
Finally, we can click on “Save” or “Apply”.
In Deepser the password manager is not present in the user portal by default, so you need to enable it.
NOTE: The end user cannot change or create new public passwords, but only view them.
1 – Go to the Deepser portal system configuration, via System->Configuration->Portal->Configurations
2 – Expand the Password label, activate the display in the portal by setting Enabled to yes and select the groups for which it should be enabled, then save.
3 – At this point, in the portal there will be available the Password section
3a – The password manager in the portal will look like this.
4 – In the portal, to change the default grid, or add a new one, go to the Password section of the main Deepser sidebar.
5 – Here it will be possible to add new grids by clicking on the ‘+‘ button, or edit existing ones by clicking on the edit icon.
Note: To learn more about editing grids, see the dedicated section.
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 (Custom 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 the following example we are retrieving devices already inside Deepser’s DataBase, to avoid duplicates when importing new records from an Excel.
We’re also retrieving Companies, Types, Subtypes and Status List Values to convert their names to corresponding IDs.
/* through the static method in Deep class, a collection of CI is retrived. The collection is filtered by class_id = 2 that represents the 'Device' class*/
$deviceCollection = Deep::getResourceModel('deep_cmdb/ci_collection')->addFieldToFilter('class_id',['eq' => 2]);
/* declaring array containing device instances */
$deviceArray = [];
/* each element of the collection is saved in an associative array, having as key the CODE field (first column of the import file) and as value the instance of the Device. The instance is a PHP object with all the data inside the Database for the record */
foreach($deviceCollection as $device){
$deviceArray[$device->getCustCode()] = $device;
}
/* declaring an array containing type-subtype tree */
$subtypesTree = [];
/* declaring array used for id->name type traslation */
$typeIdentity = [];
/* retrieving CMDB Type collection through static method getResourceModel in Deep class */
$typeCollection = Deep::getResourceModel('deep_cmdb/type_collection');
/* retrieving CMDB Subtype collection through static method getResourceModel in Deep class */
$subtypeCollection = Deep::getResourceModel('deep_cmdb/subtype_collection');
foreach ($typeCollection as $type){
/* for each type, the array tree is populated assigning the name of the type converted into uppercase
and a child array as a value, whose key 'id' corresponds to the type id
es: arrayTree [typeName] ['id'] = typeId */
$subtypesTree [strtoupper($type->getName())] = ['id' => $type->getId()];
/* for each type, the identity array is configured by assigning the id as key and name
converted uppercase as value the name attribute transformed into uppercase */
$typeIdentity[$type->getId()] = strtoupper($type->getName());
}
/* for each subtype, the types in the array tree are updated by updating child array, adding the element
that represents a subtype having as key the name of the subtype transformed into uppercase, and as
value the id of the subtype. eg: arrayTree [typeName] [subtypeName] = subtypeId */
foreach ($subtypeCollection as $subtype){
$subtypesTree[$typeIdentity[$subtype->getTypeId()]] = array_merge($subtypesTree[$typeIdentity[$subtype->getTypeId()]], [strtoupper($subtype->getName()) => $subtype->getId()]);
}
/* retrieving Company collection through static method getResourceModel in Deep class */
$companyCollection = Deep::getResourceModel('deep_company/company_collection');
$companyArray = [];
foreach($companyCollection as $company){
/* for each company, the array is configured by assigning as key the company name
transformed into uppercase and company id as value */
$companyArray [strtoupper($company->getName())] = $company->getId();
}
/* Retrieving values and keys of cmdb_ci_status list
Deep::helper('deep_list') retieving list helper which is an utility class
->loadListValues('cmdb_ci_status') retieving list elements
->toOptionHash() the return collection is converted in a key = label array
array_flip wrapping keys with vakues
array_change_key_case keys case converted to uppercase */
$statusArray = array_change_key_case(array_flip(Deep::helper('deep_list')
->loadListValues('cmdb_ci_status')->toOptionHash()),CASE_UPPE
In Deepser it is also possible to configure which columns should be visible in the Relation Grid.
To configure it, first you need to configure the form template and add the custom field to it.
See this article “Configuring a Relation“.
After this, inside the operation in the TAB “Relation”, the following screen will appear:
At this point, we have to go to the “Edit” button. Once clicked, the following screen will open:
Now you can add columns or remove them by dragging the entries corresponding to the columns from the “Available Columns” section to the “Visible Columns” section and vice versa.
Now, you will need to click on “Save” or “Apply” to save the new configuration.
Finally, you will see that the column has been added correctly.
The Service Operation fields are organized in Tabs. The default tabs are Main Data, Details, Closing Info, Activity/Attachments, Email, History, Relations and SLA .
In the following article, we will see the meaning of the main fields of an Operation, those present in the Main Data Tab.
The meaning of the fields is the following:
| Camp | Meaning |
| Title | The title of the Operation. Usually a brief description. |
| Category | The Operation category. It is a fundamental piece of information for managing the assignment to the workgroups and for cataloguing the scope of the required activity in a precise manner. |
| Status | The current state of the Operation. It is a fundamental data for the management of the life cycle of the request. |
| Priority | The priority of Operation, as the perception of importance given by the operators who are working it. |
| Urgency | The Urgency of the Operation, as the perception of importance given by the user who submitted it. |
| Company | The company requesting the ticket. It is automatically filled in according to the company to which the Requester belongs. |
| Requester | The requesting user of the Operation. In case the ticket originates from an incoming email, and this email is not assigned to any user, it is equivalent to the address from which it was received. |
| Device | Device, among those present in the CMDB, to which the ticket refers. |
| Description | The detailed description of the ticket, with any additional information. |
Operation statuses are used by default to track the lifecycle of tickets individually.
Every Status belongs to a Class, a simpler logical grouping.
The default classes for Deepser states are the following:
| Class | Meaning |
| Open | Statuses that belong to this class indicate that the request has not been resolved and has yet to be processed. |
| Closed | Statuses that belong to this class indicate that the request has been resolved, therefore the processing is finished. |
| Deleted | Statuses that belong to this class indicate that the request has been logically eliminated, either because it was rejected or because of input errors. |
The status field, by default, can take the following values :
| Status | Class | Meaning |
| New | Open | The request has just been created and has not yet been processed. |
| In process | Open | The request is in process. |
| Closed | Closed | The request has been processed and completed. |
| Reopened | Open | The request was previously closed, but reopened as a result of, for example, a non-resolving solution or a user complaint. |
| Stand-By | Open | The request is on hold. |
| Deleted | Deleted | The request was deleted logically, either due to an entry error, or due to a refusal by an operator, to continue processing. |
To install a Remote Collector you need to have previously installed an Agent, which can be converted into a Remote Collector through some simple steps that can be done directly from the user interface.
Currently, Deepser offers two options to archive this conversion. Manually, using the interface, or automatically, using the ‘convert’ button.
1- The first step to Automatically convert a regular Agent to a Remote Collector is to open the Agent form, through Asset > Device, then select the Agent you want to convert.
2 – Then, press the Convert to RC button, this will trigger the conversion request.
3 – A Dialog will open, asking for confirmation, click YES.
3b – The request will be sent, press Enable to get to the Remote Collector Grid.
4 – If the process finished without errors, the remote collector will be available, open it.
5 – To enable the Remote Collector to work in the network, click on the Enable button.
6 – If you want to Disable the remote collector, click on Disable.
Go to the ‘DeepAgent’ entry added to the Start Menu, by clicking on it the Agent user interface will open.
In the second tile, there is the interface for converting an Agent into a Remote Collector.
To convert the Agent click on the ‘Convert to Remote Collector’ button.
At this point go to the System>Asset Configuration>Remote Collector section of the Deepser back-end.
In the grid there will be a record representing the conversion request (from Agent to Remote Collector) sent by the device, the status of the request will be ‘Pending‘.
Click on the ‘One Time Password’ cell to copy the OTP directly to the clipboard, or open the request form and copy the content of the ‘One Time Password’ field.
Once the ‘One Time Password’ has been copied, return to the Agent user interface, and paste it in the text field on the Remote Collector tab.
Now the Agent can be converted into a Remote Collector, click on the ‘Validate OTP’ button to proceed, at this point the user interface will automatically close and the background conversion procedure will begin.
Once the conversion process is finished:
The user interface of the Remote Collector displays only the status of the service, all configuration tools and controls are accessible from the Deepser back-end under the section SystemàAsset Configuration.
At this point, it is possible to configure scan jobs that will be performed by the Remote Collector, which will recover data from devices connected to the network.
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.
To be able to create entities, from incoming emails, it is necessary to define an incoming mailbox, and then associate this mailbox to related email rules.
This guide will explain how to configure an IN mailbox.
Important Note: based on the settings of your email server, all incoming messages could be deleted after Deepser has processed them. This is the default behaviour of the software with email servers like Exchange, Standard SMTP Servers, etc.
Be very careful when configuring the incoming email integration, do a test and a backup. Remember also that Deepser processes all the emails in the inbox, so if the mailbox is full of messages (eg: the first time we run the integration) a lot of records could be created.
To avoid this situations, not directly caused by Deepser, we advise always to do a test on mailboxes with few messages.
To configure a mailbox within Deepser, in the backend navigation menu, navigate to the System->Tools->Email->Mailbox section.
The grid in this section shows already configured mailboxes.
To configure a new mailbox click on the ‘+ Add Mailbox‘ button in the top right corner.
At this point the mailbox configuration form will appear.
Once the mailbox type has been set, in this case ‘IN‘, all the relevant fields will be loaded dynamically.
The fields in the form have the following meaning:
| TAB | FIELD | MEANING |
| GENERAL DATA | Name | Name of the mailbox. It is the name used in the select-boxes. |
| Type | IN o OUT (IN to receive emails, OUT to send). | |
| Status | If “Disabled” the integration will not be considered by the system. | |
| Host | Address of the mailserver. | |
| Port | Port for the connection to the mailserver. | |
| Encryption | Encryption of the connection.. | |
| Username | User name to read the mailbox (usually it is the email or the Exchange user associated to that mailbox). | |
| Password | Password to login to the mailbox. | |
| Protocol | Protocol to get the emails (POP3, IMAP or OWA). | |
| OAuth Client | OAuth2 client used for the authentication, if required. | |
| SITEMA DATA | Model | The field Model represents the entity of Deepser in which to look for a record linked to the received emails. If we set for example DeepService – Operation the mailbox will create and update records of Operations. If we set DeepAdmin – User the emails will used to create or update users. |
| Model Field | It is the field of the entity Model where to check if a record already exists. If we set the ID (field: entity_id), then the check will be done on entity_id (unique ID) of the Operations. | |
| Prefix | It’s the prefix we prepend to the Model Field, to search the record. If we set the Model Field equals entity_id of the Operation, then the email integration verifies the subject of the email: if after the Prefix there’s an ID of a record already in the system. After the expression Prefix and until the first blank space, the ID of the model will be searched. Thus, if we set the field Prefix with the value TICKET# and the Model Field with the value entity_id, if we receive an email with subject TICKET#70, then Deepser looks for an Operation with ID 70. If Deepser finds that record, then the record is updated and the rules applyed to update the record are that in the Update Expression field. If we receive an email with a subject Hey this is a new ticket then Deepser creates a new record, following the rules in the field Create Expression. | |
| Outgoing Email Box | We can teel the system that for every record created using this mailbox we will use the specific outgoing mailbox to send notifications. | |
| Apply Email Rules | If yes related email rules are executed. | |
| Allowed Emails | If we can receive email from all emails or only from registerd users. Ignored mails will be deleted. | |
| Spam Expression | In this field it’s possible to define a regular expression to check the objects of incoming mails in case they should be identified as spam. If the emails are ignored they are deleted from the inbox. | |
| ADVANCED | Cron Expression | Cron Expression that defines the frequency of the scan of Deepser. If this expression is not set, this mailbox will not be processed by Deepser. |
| Processed on | Date and time of the last scan of the mailbox. | |
| Custom Code | PHP custom code run after the email has been received. It is possible to configure this field to trigger custom events after the email has been received. For example, if we want to receive a counter of the reminders or to update a specific entity of Deepser after we have received the email, we can customize this field to do that. |
Once the form has been filled and the configuration saved, click on the ‘Check‘ button, top right, to test the configuration.
If the mailbox has been configured correctly you will see a message of successful connection, otherwise an error message.
The Home Page of Deepser contains all the information regarding the module selected in the Navigation Menu.
By default, the first screen showed to a backend user after the login is the Dashboard, where you can see the graphs to easure the quality of your service real-time.
Note: The initial page of a backend user can be changed by system administrators.
To understand the details, the functions and the structure of the Home Page of Deepser, we will take a look at the Service Module.
Click on the item “Service” in the Navigation Menu on the left, we will see the sub-menus with all the Service Types in the system.
Note: the item “All” is always present and it is used to access all the Requests, without filtering the Service Types.
Selecting a menu item, the main screen of Deepser will show a grid with the requests (Operations) in the system and visibile based on the current user’s permissions.
In Deepser it is possible to configure the way in which the search between the various articles is carried out, allowing to obtain better results. Various filter types are used to do this.
The proposal of articles related to the scope, for example, of the Service Operation that is being created takes place through the appropriate configuration of search filters.
The order in which the articles are proposed is degressive compared to the number of positive matches between current model and article.
It’s the standard filter, the search looks for a match between the title of the Service Operation and the tags defined in the Knowledge Base articles.
To filter into the “article body” (Description field) you need to change the configuration from the Systemconfigurationknowledge Base > Configurations > search from the Deepser backend.
The form fields have the following meaning:
| Field | Description |
| Use description in search | If set to YES the search content (for example the title of a ticket) is searched in the body of articles. |
| Redirect the Search Data | If set to YES, the KB search indexes are re-created. |
| Maximum number of results | Maximum number of articles proposed in the search results. |
It can often be useful to set the same value to several different tasks. In these cases, the use of massive actions is effective.
At the moment, the only massive action already prepared by the system in the global task grid is that for the (physical) elimination of one or more tasks.
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 massively change the state of one or more different tasks.
The code must be inserted directly into the custom PHP script area.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | // retrieve all states from the list task_task_status as associative arrays$taskStatusArray = Deep::helper('deep_list')->loadListValues('task_task_status')->toOptionHash();// initialize html component$this->addMassActionItem('status', [ 'label' => 'Change Status', 'additional' => array( 'status' => array( 'name' => 'status', 'type' => 'select', 'class' => 'required-entry', 'label' => 'New Status', 'disable_js_select' => true, 'values' => $taskStatusArray, ) ), //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 tasks $collection->addFieldToFilter('entity_id', ['in' => $this->getIds()]); // $collection contains the instances of the selected tasks and we iterate on them foreach($collection as $task){ //$this->getValue() contains the id of the new status, the selected one //set the new status $task->setStatus($this->getValue()); //save the task $task->save(); } }]); |
By entering this script, you can then select one or more tasks and change their status to the selected one.
A question may have popped in your mind:
“How can I view all the steps and processes executed into a workflow?”
In Deepser inside the “Flow” module there is a section called “Execution”.
After opening your Deepser Backend portal, by clicking at “Flow” module and “Designer” module
And, by clicking the “Executions” tab located at the top right, the following screen will open:
Here is shown the number of times when the flow process called “Flow Approval Multi Stage” has been executed.
The first execution was completed, instead the second execution is set in status “Waiting”, which means that the flow needs to be approved or to be refused.
Inside the second execution the following screen is shown:
In this example, we can see that the flow process is still waiting into a specific stage and inside a specific block of action.
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, 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.
To create a new user in Deepser you will need to go to the menu System -> Permissions -> Users
In the screen that will open, you will need to click on the “Add User” button
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 username. |
| 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 exemple the Users role, who by default see 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.
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 presents 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 on that has visibility and one in that does not have it, then the resource will be visible.
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.
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.
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:
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.
Create an APP Registration (API)
Enter Name, Supported Accounts, and Redirect URI of the OAuth client configured in Deepser.
Create an Authentication with Platform WEB and put the url of the application (only https) – Type claim ID Tokens
Create a secret
Set claim IDs
Add permissions for Microsoft Graph and then run the Grant admin permission
Now switch to application management in ENTERPRISE APPLICATION
In User and Groups add the enabled users
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 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, 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 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 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.
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.
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.