Difference between revisions of "Features/Advanced input forms"
(→Usage) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
In case you need step-by-step questionaires or wizards, we recommend looking at [[Features/Questionaires|Questionaires]] | In case you need step-by-step questionaires or wizards, we recommend looking at [[Features/Questionaires|Questionaires]] | ||
TS has implemented more than 160 fields of various types, as documented in the [[Field_type_reference|Field reference]] | |||
== Validation rules == | == Validation rules == | ||
| Line 24: | Line 26: | ||
== Field dependencies == | == Field dependencies == | ||
Fields can be dependent on values in other fields. Specific values, value ranges or list of values. | Fields can be dependent on values in other fields. Specific values, value ranges or list of values. | ||
Show SUBCATEGORY if CATEGORY contains either Foo, Bar or Foobar | |||
Show field NOTES if PRICE is higher than 1000 | |||
In case the dependency is even more complex, an expression written in JS can be defined and linked to the field | |||
== Workflow dependencies == | == Workflow dependencies == | ||
| Line 40: | Line 48: | ||
Learn to setup [[Features/Status level dependencies]] | Learn to setup [[Features/Status level dependencies]] | ||
== Lookup fields | == Lookup fields == | ||
TS contains alot of specialized lookup fields that have defined datasources ready | TS contains alot of specialized lookup fields that have defined datasources ready | ||
* Danish postal codes | * Danish postal codes | ||
Latest revision as of 08:18, 11 November 2024
Usage
In TS it is possbile to configure very advanced and dynamic input form behavior. The goal is to minimize the effort required to enter data, and at the same time maximize data quality.
In case you need step-by-step questionaires or wizards, we recommend looking at Questionaires
TS has implemented more than 160 fields of various types, as documented in the Field reference
Validation rules
Validation of field values can follow one of the following
- The value is required
- Can be validated by a Regex expression
- Have a value within a minimum and/or maximum
Value ranges will differ according to data type
- Numbers: The value
- Text: Length of text
- Date: Allowed years
- Filles: Number of files
Note that dependencies are resolved before validation, so in case a field is not relevant the validation rule will be ignored.
Instrcutions
- Click on field
- Check of Validation
- Remove check in Allow empty values
Field dependencies
Fields can be dependent on values in other fields. Specific values, value ranges or list of values.
Show SUBCATEGORY if CATEGORY contains either Foo, Bar or Foobar
Show field NOTES if PRICE is higher than 1000
In case the dependency is even more complex, an expression written in JS can be defined and linked to the field
Workflow dependencies
Fields can be dependent on the records location in the workflow governing that entity. Each status is assigned a status level.
Fields can then refer to the workflow model with restrictions
- Status level FROM
- Status level TO
If the status restrictions are not satisfied the field will be removed and validation requirements will be ignored.
Note that 0 signifies that the status level restriction is disabled.
Instructions
Learn to setup Features/Status level dependencies
Lookup fields
TS contains alot of specialized lookup fields that have defined datasources ready
- Danish postal codes
- Danish addresses (DAWA)
- Countries and currencies
- NACE codes (tree searchble)
- UNSPSC codes
- SKS framework (7 subtypes)
The DAWA lookup can also work together with a Google Map. Entering an adress wil update the map with the location, and clicking on the map will find the adress.
Duplicate prevention
To ensure that the same data are not duplicated by mistake, it is possible to ensure that new records are unique based on values in one or more fields.
Learn to set up Features/Duplicate_prevention