I want to be able to restrict the user from entering special characters like !@#$% in a text field in a form. I could not find any such utility in the Form Builder or Data Modeler. If my understanding is correct, I should be using a workflow for this. But I am not sure how to do it. Any suggestions?
Do you want the field to disallow spaces and numeric characters, as well as special characters like !@#$%? If yes, then Validation > “Alpha Only no Spaces” through Data Modeler may help you…
If you opt to go the workflow route, you could have a switch that uses a few Contains() statements to check for the individual characters you don’t want, but I don’t know how well that function will work with special characters. You may want to look at using the isStringPatternMatch() function, as described in this thread.
[Admin: To see other related posts, use the Character tag.]
The IBM TRIRIGA Connector for Business Applications (CBA) has the saveRecord() method. If saveRecord() runs without an action parameter, it triggers not-audited field validation (read-only, formulas, etc.). Is it fine to use this method without an action name?
For example, saveRecord could call a state transition by its name in a parameter. But a record could be in any state, so this state transition could be not-applicable to the current state. What if a record receives the wrong transition? (I guess InvalidActionNameException.) Should this situation be handled by process design? Or by state validations in the code which is difficult to maintain? Or another way?
[Admin: To see other related posts, use the CBA tag or Connector tag.]
When the user go through the Object Label Manager to access a form and change the name. The system allows you to name it the same as another form, resulting in duplicate form names. There is currently no error handling for this. Meanwhile, if you access the form from the Form Builder itself and try naming it the same as another, the system will give you an error.
The issue was that the link into Form Builder from Object Label Manager’s Labeled Objects tab was not passing in the module ID and the BO ID for the form, thus the unique name validation for the module was failing to occur. This fix obtains the the module ID and BO ID for the form selected and correctly passes it to Form Builder. Moving forward, we resolved an issue in Object Label Manager, where opening a form from a link under the Labeled Objects tab would allow a user to change the name of the opened form to a name that already existed in the form’s module.
[Admin: To see other related posts, use the Object Label Manager tag.]
Moving forward, we resolved an issue where malicious files can be uploaded via document upload by bypassing the client side validation.
[Admin: This post is related to the 01.25.16 post and 07.18.15 post about restricting the upload of certain file types. To see other related posts, use the Vulnerability tag or CVE tag.]
If you make a field required, such as the “Description” field, and you copy and paste spaces from a Word document into the “Description”, you will be able to submit the request. Essentially, you have a submitted record, where the “Description” is required but still blank. Meanwhile, if you attempt to create a request with a “Description” where you manually enter the spaces, it will not let you submit it.
Moving forward, a text field value containing only spaces and/or carriage returns will be considered as empty, and will fail the required field validation, if applicable.
When having two business objects (BOs) with the same name in different modules, and you select the “Validate” check box on DataConnect (DC) runs, this will cause an SQL statement (built to receive a single row, the BO name) to fail, since the logic does not include the module on the WHERE clause.
The DataConnect job issue was that the File-to-DC validation logic had SQL that assumed BO names are unique, and did not account for same-named BOs in different modules. This fix includes a module name parameter to the logic, so that the SQL knows from which module to retrieve the BO. Moving forward, we resolved an integration object File-to-DC issue involving the “Validate” check box. When the “Validate” check box was selected, the validation process would fail if the BO being validated had the same name as another BO in a different module.
[Admin: To see other related posts, use the DataConnect tag.]
Users are encountering a spinning wheel when clicking on multi-tabs (sub-tabs) other than the main tabs. The system hangs and freezes. Users will then log out or close the application. For some users, it works fine, but for other users, it does not. This is related to a security group issue on the TRIRIGA 3.5.2 platform.
We needed to move the logic of how the platform validates section actions closer to where the actual action is taking place. Moving forward, the user will be able to navigate between multi-tab sections, if they have read-only access on the section.
[Admin: To see other related posts, use the Security tag.]