| Version | Date | Notes | By |
|---|---|---|---|
| 1.0 | 2023-06-21 | Initial release | ROB |
Recently, the process engine has been completely reworked to be independent from the dynamic attribute system managed from the administration, with very few exceptions. Data types of type table or tree still have these tables or trees being registered in the administration.
This means that the tipification of variable definition attributes is done from this system. It is from here that the relation between type and multiplicity of a given attribute is made with the frontend form components that can be used as well as the laravel validations that can be applied to it.
The data type system has no management interface and new data types can only be added via a migration that correctly seeds all relevant tables. Bellow, these tables will be detailed.
| column | description |
|---|---|
| type | Slug of the type of attribute. Can be a primitive (int, float, string, bool, date, dateTime, mediumText and time) or the fully qualified class name of the model (in which case the attribute will store the id(s) of that model's table) |
| multiplicity | The multiplicity of the attributes (can be single or multiple) |
| default_types | json This field indicates what "types" are acceptable for a default value, "value" means that the default value is set directly (by the user) and "now" is the system date time (the part that does not matter gets removed for just time or just date) |
| module_dependency | This needs to be set to the slug of the module the type depends on (if the module is not installed, this will not be displayed / used) |
| schema_constructor_type | This stores the name of the function that generates the attribute column in the dynamic tables (for example User::class type === 'unsignedInteger()' or 'int' === 'integer())' |
translations.name |
name of type (translations table) |
Once the type has been defined, other information will be needed like acceptable form fields and validations.
This table establishes the relation between validations and data types (if more validations are needed, they need to be added to the t20_data_standard_validations; non standard laravel validations are added via WeFlow™ scripting language, so there is no need to worry about it).
| Column | Description |
|---|---|
| data_type_id | id of data type |
| validation_id | id of validation |
These tables store the standard validations currently available for use in SGU™ as well as what additional parameters are needed for each validation.
This is not complete, many laravel validations are not yet implemented here
The t20_data_standard_validations has the following:
| Columns | Description |
|---|---|
| slug | laravel validation slug (required, required_if, ...) |
| label | label translation slug (translated in frontend) |
And the t20_data_standard_validation_params has the following:
| Columns | Description |
|---|---|
| standard_validation_id | Relation back to t20_data_standard_validations table |
| slug | slug of the parameter |
| order | allows ordering of the parameters |
| label | translation slug for parameter label (translated in frontend) |
| type | type of parameter |
| required | 0 or 1 |
In the parameters, if the type is:
This table establishes the relation between t20_data_types and t20_data_frontend_forms. A single data type can have multiple valid frontend form components.
| Column | Description |
|---|---|
| data_type_id | id of data type |
| frontend_form_id | id of frontend form |
This table contains all the fields that can be associated with the t20_data_types as valid field of a data type.
| Column | Description |
|---|---|
| slug | frontend slug as type for schema-form component |
| label | translation slug (translated in frontend) |
The validation rules are set when designing a form for a given task (each form component can have multiple validation rules).
The actual validations are performed as normal in the UpdateRequest for MyTasks. A model trait called GeneratesValidationRules (aplied to InterfaceSystemComponent, the request helps collate the validation rules from each component that has them).
The validations (rules) and attributes are gathered and passed as returns in the request, as normal (returning associative array from rules() and attributes()).