How Can We Help?

Form Templates

 
All forms to edit records in Deepser are customizable using a visual editor. We can also apply a template to every form, based on the data contained in the form.
The template, infact, can be manually chosen by a user or it can be set based on some rules configured on the values of the fields of the record.
To uderstand better, let’s make an example.

 
In the first case, an Agent that often opens new requests, wants to define a minimum set of data to make the process of inserting a record faster and also to make some fields mandatory.
Inside the record (in our example in the Service Operations) it is possibile to select a specific template, using the button to select the form templates:

 

 
In the second example, it is possibile to configure a form for a certain category of Service Operations. If we change the value of that category, we can automatically tell the system to reload the form and to modify its layout.
This is useful when we want to ask specific information to the requester users, differentiated by category (or other fields).

 

 



 

Theory of Form Templates

All entities in Deepser have a default form template.
This default Form Template is applied to an entity if Deepser doesn’t find other templates configured by the Administrators.

 
When a record is saved into the system with a specific Form Template, this is stored into the DataBase and cannot be modified by the system. At this point, the only way to modify a Form Template is manually by an operator.
This basic behaviour of Deepser assures that if a record with a Form Template has already been saved in the system then we always see the set of information and the layout displayed by that Form Template. Obviously, as we said before, we have the flexibility to change the Form Template manually.

 
The Form Template can change dynamically when the record has not yet been saved inside the DataBase.
This behaviour lets us define a set of information (and the layout of the inserting form) based on the values of the fields we are filling.
As said before, if we need a particular layout or set of information for a certain category or Service Type, we can configure as many Form Templates as we need.

 
The dynamic change of the Form is possible because Deepser can define a set of rules (Form Template Rules) that are configured when creating a new Template.
The Form Template Rules are fundamental to dynamically change the templates and must be implemented with attention to create a powerful and flexible system of dynamic forms, that auto-fit based on the data we are inserting.

 



 

Create a new Form Template

To create a new Form Template, from the Form screen inside a record (if we are logged in as Administrator or Agent) it is possibile to select the menu New Form Template.

 

Insert the name of the Template:

 

Now the template is created and it is applied to the record we are editing.
Notice that a new template has always the same fields of the original template.

To modify the template, click on the button:

 

We access the screen to configure the Form Template.
This screen is divided into 2 parts: left side with the tree of the entities of the Form and the central side with the configuration details.

 

Based on the entity selected on the left side, the central and right side are modified:

 

 



 

Structure of the Form Template

A Form Template is structured hierarchically in a system of containers elements.

 

At the first level we have the Form, that contains a set of Tabs, that contains Fieldsets. Every Fieldset has a variable set of fields.

Note: fields cannot be replicated on different Fieldsets, so if we insert a field in a specific Fieldset we cannot insert this field (for example) in another Tab.

 
By an interface perspective, all the settings are translated into the form visualization:

 

To add new elements in the form template, right click with the mouse and add the “sub-element” chosen.

 

When we add new tabs and fieldsets, we can edit them by drag&drop.

 
Under the tree with the structure of the form it is possibile to configure also the Buttons of the form.
The basic navigation buttons are: [Back], [Reset], [Save], [Apply] (Apply saves the form and stays in the form, while Save redirects to the main screen of the entity that is often the grid of that entity), but it is possibile also to define custom buttons.
Furthermore, buttons can be displayed on the header or on the footer to make the interface easy to use.

 

 



 

Buttons Configuration

To add a new Button, right-click on the item Buttons and select New Button.

 

We will see a new item in the Buttons tree. To edit, click on it and set the configuration in the middle of the screen.

The fields have the following meaning:

 

Field Meaning
Label Label of the button.
Code Internal code to identify the button.
Area Header or footer.
Status If Disabled the button is not active.
Class CSS class to display the button.
On Click Custom code triggered when clicking the button.

 



 

Form Configuration

The configuration of every single item of the Form is done by the edit screen:

 

The fields have the following meaning:

 

Field Meaning
Name Name of the Form Template.
Code Internal code to identify the form template.
Status If Disabled the form template cannot be applied.
Script Here we can write custom code to change the form behaviour.
This field must contain PHP code that returns a string with a javascript function.
Init Script Here we can write custom code to change the form initialization.
This field must contain PHP code that returns a string with a javascript function.

 



 

Configure Tabs of the Form Template

Tabs configuraton is accessible after having clicked on the Tab element in the tree:

 

The fields have the following meaning:

 

Field Meaning
Label Label of the tab.
Code Internal code of the tab.
Status If disabled the tab will not be displayed.
Class CSS class to display the tab.

 



 

Configure the Fieldset of the Form Template

The configuration of Fieldsets is accessible after having clicked on the Fieldset element in the tree:

 

We can define the name and status of the Fieldset.
Inside the Fieldset we can insert the Fields visibile in the form.
On the left side we have all the available fields, in the middle we have all the visibile fields.
It is possibile to edit fields inside a Fieldset with drag&drop.
To delete a field inside the Fieldset, move it to the column “Available Fields” on the right.
Doing so, we can use this field in other fielsets.

 

 



 

Configure the fields of the Form Template

The fields of the Form can be edited inside Fieldsets.
To change the layout and the configuration of every single Field, click on the “cogwheel icon” in the Field box.

 

We see the popup to manage the Field configuration:

 

The fields have the following meaning:

 

Field Meaning
Default Value Default value of the field. For that Form Template, when a user opens the form he will see for all new records that value.
Disabled If not active the value will not be saved.
Readonly Read-only field.
Required MAndatory field. If manfdatory, the form will not be saved until this field is filled in.
Reload Form This field is important to apply the Form Template Rules. If “Yes”, when a field changes, then the form is reloaded and the Form Template Rules can be applied.
When this value is set to “Yes” we reload the template also when we change some specific fields, like company or assigned group. This is important if the field is interdependent with other fields (the assigned group changes also the values in the assigned user select-box).
Columns The size of the field. Maximum value is 3 and minimum is 1, see the screenshot:
Hidden The field will be hidden in the form.

 



 

Create a new Form Template Rule

Now that we know almost everything about the structure of the form, we can examine the Template Rules.
First of all, remember that to apply a rule dynamically we must set the Reload Form value to Yes.
To create or modify a rule click on “Edit Rules”:

 

Now we are editing the current form rule. To edit the rules of other forms we need to open another form template and do the same process.
Here we can find two fields.

 

Field Meaning
Priority Priority of the rule. Rules with higher priority are applied first.
Rules Field with PHP custom code that returns “true” or “false” based on the conditions to apply the template.
To understand this field, we provide an example.
We want to define a rule to change the form template if the status of the request is New and we want to change the template when the status changes.
It is necessary to define for every form template that the Status field will reload the form:

 

Then, define the following rule to change if the Status = New:
[php]
if ($this->getModel()->getStatus() == 1)
return true;
return false;
[/php]
And set the priority higher than the default priority (the default template has always priority = 0, so insert a number greater than 0).

 
Now, however, we must edit also the default template, changing the Status field with the attribute “Reload Form = Yes” and then modify the Form Template Rule of the default form:
[php]
if ($this->getModel()->getStatus() != 1)
return true;
return false;
[/php]
Leave priority to 0.

 
Doing so, the new template (non-default) will be applied if the status is “New”,otherwise we apply the default template.

 



 

Apply Form Templates to the User Portal

We have seen a complete guide on how to edit Form Templates in the back-end.
We can configure Form Templates also in the user portal.
This configuration is useful to guide the users to insert the information needed by our support when opening a new request. For example, if we need different information based on the category or the type of the request, we can use different form templates.
To configure Form Templates in the User Portal use the same process seen in this chapter.
Teplates of the end user portal can be modified by clicking on the menu System > Portal > Operation.

 

Go inside an Operation form and edit the Form Template with the specific button.

 

Now follow the same procedure for the back-end as discussed in this chapter.

Table of Contents