The Forms addon consists of an i-doit compatible addon and a backend application. The backend is responsible for data management and can be controlled by a REST API. It is still possible to use i-doit as a proxy to communicate with the Forms backend. However, this requires a valid user session in i-doit. If this is not the case, the Forms backend API can also be addressed directly. This document assumes direct communication.
It should be noted that the backend does not contain any logical validations. This task is exclusively performed by the frontend. Direct use of the API therefore entails a complete waiver of control structures. This should therefore always be taken into account when used in this way.
It must also be considered that for the use of i-doit attributes, the Forms addon API is also required to access essential attribute information.
The authentication against the forms backend is based on username and API key. This information is about those configuration parameters which have already been stored in the i-doit configuration:
If the authentication is successful, you will then receive a JSON web token:
123
{
"access_token": "{JWT_TOKEN}"
}
From now on, the token must be specified in every request if endpoints that require authentication are addressed. This is done via the Authorization -Header. Below is an example:
12
GET http://localhost:3000/api/form
Authorization: bearer {JWT_TOKEN}
By default, a token is valid for 60 minutes after it is created. After this time it loses its validity and you have to ‘login’ again.
GET http://localhost:3000/api/form/6245bf4f36f695945b3df9be
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJfaWQiOiI2MWU2YThlNmY1ZTMxYjI5NzAwOTMxOWEiLCJuYW1lIjoic2VsY3VrIiwic3ViIjoiJDJhJDEwJFJ4YlRybVpUVXlXc1NSQ2VZTFR6enVBZXJZTUF1dUlsNU5qOWt5RFN4WXlFL0NsdG1iLmY2IiwiaWF0IjoxNjU3MjkyNTAxLCJleHAiOjE2NTcyOTYxMDF9.yEZAjFAGpOCbDsJuI_vqot5J75MOE0bKPPn8osQS0Ik
This endpoint must be used to create new forms. The definition is made by using JSON and must have the following structure:
1 2 3 4 5 6 7 8 910
{
// Name of Form
"name": "My Form",
// Structure
"shape": {
...
},
// Release Status
"published": false
}
The structure of the form is specified under shape. In general, it was designed to represent a normalized and hierarchical structure. For this it contains all available node elements on the first level. This includes not only headings, texts, dividing lines, i-doit category attributes, but also pages.
It must be ensured that the node IDs (root, PAGE_1, PAGE_2,…) are unique and not repeated.
The available configuration parameters of a node are type-dependent. In general, the following data structure can be identified:
1 2 3 4 5 6 7 8 910111213141516171819202122
{"NODE_1":{// What nodes are contained in "NODE_1" - Specification of NODE-ID"children":["NODE_1.1","NODE_1.2"],// Configuration parameter for "NODE_1""config":{// Type of node"type":"NODE_TYPE",// Direct configuration parameter"props":{"parameter_1":"","parameter_2":"",[...]}}}}
The root node is particularly important here. This represents the entry point on the basis of which a form is built up hierarchically.
{
"Text165729439981501359363935038671": {
"children": [],
"config": {
// Node-Type: Text
"type": "Text",
"props": {
// To be displayed text
"text": "Page 2 Text",
// Placeholder: Displayed if the content is emptied in the frontend
"placeholder": "Enter your text",
// Visibility: Should the element be hidden?
"hidden": true
}
}
}
}
Compared to the previous types, this type is more complex and therefore contains a greater number of configuration parameters. To which these parameters can change differentiate further by type of category attribute.
The basic data structure is described below using the example of the attribute General > Title:
{
"Attribute165731273460305039947937820184": {
"children": [],
"config": {
// Node-Type: Category attribute
"type": "Attribute",
"props": {
// Attribute-ID: Composed of the category constant and the technical attribute identifier
"attribute": "C__CATG__GLOBAL.title",
// Default label of the field in the form if "label" is not specified
"defaultLabel": "Bezeichnung (Allgemein)",
// Field title
"label": "TITLE",
// Is this a mandatory field?
"required": false,
// Is the attribute required on the i-doit side? Natively or via the validation configuration.
"isSystemRequired": false,
// Label of category
"categoryLabel": "General",
// Type of attribute
"type": "text",
// Is the field visible?
"hidden": false,
// Default value
"defaultValue": "Default Value"
}
}
}
}
Some configuration parameters are dictated by the Forms addon API. They can consist of both static and dynamic values:
attribute*: static value
type* : static value, reflects the attribute type
isSystemRequired : variable value, calculated based on validation or natively
This parameter overwrites required if the attribute is required on the system side.
defaultValue : variable value, is pre-filled if the object type addresses a default template that defines a value for the attribute
An incorrect specification of isSystemRequired will inevitably result in an error when submitting the form unless required is true. defaultValue is not absolutely necessary if the values from the default template are not to be taken into account.
All of this information can be obtained via the Forms addon API, as mentioned earlier:
1
GET https://idoit-instance/forms/api/attribute?category=C__CATG__GLOBAL,C__CATG__ACCOUNTING&class=C__OBJTYPE__SERVER
Here, category contains a comma-separated list of category constants. class on the other hand contains the object type constant and is needed to determine defaultValue. The return looks like this:
i-doit has attributes that depend on another attribute within the category. A very simple example is the attribute Model > Model, which depends on Model > Manufacturer.
For this purpose, the Forms addon contains frontend control mechanisms, for example to recognizes the use of Model > Model (Child) without Model > Manufacturer and in this case adds the parent attribute automatically.
These attributes can be identified based on their metadata. The child attribute contains parent information and the parent attribute children information:
GET https://idoit-instance/forms/api/attribute?category=C__CATG__MODEL&class=C__OBJTYPE__SERVER