User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:adminmanual:businessmappings:validations [2020/01/17 19:10] joebordes |
en:adminmanual:businessmappings:validations [2020/10/30 10:41] (current) joebordes [Validation Business Mapping] |
||
|---|---|---|---|
| Line 86: | Line 86: | ||
| *restrictions: date in ISO format | *restrictions: date in ISO format | ||
| *dateAfter - Field is a valid date and is after the given date | *dateAfter - Field is a valid date and is after the given date | ||
| + | *restrictions: date in ISO format | ||
| + | *dateEqualOrAfter - Field is a valid date and is equal or after the given date | ||
| *restrictions: date in ISO format | *restrictions: date in ISO format | ||
| *contains - Field is a string and contains the given string | *contains - Field is a string and contains the given string | ||
| Line 100: | Line 102: | ||
| *IBAN_BankAccount - validate IBAN Bank Account number | *IBAN_BankAccount - validate IBAN Bank Account number | ||
| *restrictions: none | *restrictions: none | ||
| - | *EU_VAT - validate EU VAT number | + | *EU_VAT - validate EU VAT number: the EU VAT validation checks if the VAT no. is in use, which implicitly checks the format |
| - | *restrictions: none | + | |
| - | *notDuplicate - checks that no other record with the same value exists on the given fieldname | + | |
| *restrictions: none | *restrictions: none | ||
| + | *notDuplicate - checks that no other record with the same value exists on the given field name | ||
| + | *restrictions: list of [[https://discussions.corebos.org/showthread.php?tid=1934&pid=8265#pid8265|other fields you want to combine]] with the main field to search all at once | ||
| *expression - accept a workflow expression map and evaluate it in the context of the new screen values | *expression - accept a workflow expression map and evaluate it in the context of the new screen values | ||
| *restrictions: map name or id | *restrictions: map name or id | ||
| + | *validateRelatedModuleExists | ||
| + | * retriction: related module name | ||
| *custom - launch custom function that can be found in the indicated file | *custom - launch custom function that can be found in the indicated file | ||
| - | * restrictions: file name, validation test name, function name and label to show on error (will be translated) | + | * restrictions: filename, validation test name, function name and label to show on error (will be translated) |
| + | * parameters: parameters can be passed to custom functions using the parameters-parameter directives | ||
| <WRAP center round info 100%> | <WRAP center round info 100%> | ||
| - | All of the rules above accept an optional directive named __message__ where you can set the error message you want the user to see when an error on that field happens. If this is not established a standard error message will be returned. Inside this message you can use the curly brace __field__ tag to indicate where you want the field name to appear: | + | The parameters directive permits us to send values to our custom validation method with a structure like this: |
| - | <message>This is my custom msg for field: {field}</message> | + | <code XML> |
| + | <parameters> | ||
| + | <parameter> | ||
| + | <name>name of variable</name> | ||
| + | <value>value of variable</value> | ||
| + | </parameter> | ||
| + | </parameters> | ||
| + | </code> | ||
| + | these parameters will be sent as a name indexed array to the function | ||
| </WRAP> | </WRAP> | ||
| - | <WRAP center round info 100%> | + | ===== Validation Message ===== |
| - | The trigger for these maps is that they must be of type "Validations", the "Target Module" must be set correctly and the name MUST end with "_Validations". If more than one record is found, they will ALL be applied. | + | |
| - | </WRAP> | + | All of the rules above accept an optional directive named __message__ where you can set the error message you want the user to see when an error on that field happens. If this is not established, a standard error message will be returned. Inside this custom message you can use the curly brace __field__ tag to indicate where you want the field name to appear: |
| + | |||
| + | <code XML> | ||
| + | <message>This is my custom msg for field: {field}</message> | ||
| + | </code> | ||
| + | |||
| + | Besides this option, which covers almost all the use cases, we have run into an edge case where we needed the message to be dynamically set. The problem with this is that the way the valitron library works we need to give it all the rules and messages before we start but in this case, we didn't know the message until the validation was launched. So we added support for defining the message before validating the rule for custom functions. | ||
| + | |||
| + | To retrieve the message to be used, the validation map will look for a function with the same name as custom function concatenated with the string "GetMessage". So, if we have a custom rule named "validateFlowStep" and we define another function named "validateFlowStepGetMessage", then the validation map will execute this second function giving it the same parameters as the validation function plus the current validation message. This way your custom validation function can determine which message to return. This is almost like launching the validation twice, so it comes at a price. | ||
| + | |||
| + | You can see an example of this in the [[https://github.com/coreBOS/ProcessFlowPerspective|BPM Process Flow Perspective]]. Look in the Process Flow module for the validateFlowStep script. | ||
| + | |||
| + | ===== Activating the validation maps ===== | ||
| + | |||
| + | The trigger for these maps is: | ||
| + | * they must be of type "Validations" | ||
| + | * the "Target Module" must be set correctly | ||
| + | * the name MUST end with "_Validations" | ||
| + | |||
| + | If more than one record is found, they will ALL be applied. | ||
| + | |||
| + | So, as with most business maps, what activates the map is the name, but as a difference with other maps this type of map can have more than one and they will all be merged and applied. | ||
| + | |||
| + | This type of map also supports the Global Variable configuration as all the other business maps. In this case, the global variables will all be obtained and evaluated, so you can have more than one global variable and they will ALL be added to the Business Maps that are found by name. | ||
| + | |||
| + | The idea is that we can have global validations for all users using the business map trigger name (ending with "_Validations") and then define other business maps with any other name and activate these per-user or role using the global variable "**BusinessMappings_Validations**". This global variable MUST have the correct module selected (only one). | ||
| + | |||
| + | |||
| ===== Accessing other fields in the form ===== | ===== Accessing other fields in the form ===== | ||
| Line 198: | Line 239: | ||
| </code> | </code> | ||
| + | |||
| + | ===== Accessing via web service ===== | ||
| + | |||
| + | Validation maps have their own web service end-point: **ValidateInformation** | ||
| + | |||
| + | Also, we have **CreateWithValidation**, **UpdateWithValidation**, and **ReviseWithValidation** | ||
| ===== Some other examples ===== | ===== Some other examples ===== | ||
