Looking for help?

Submit a request

Brazos UI Modal - Boundary Events and Validation




  • Avatar
    Jay Rosenberg

    Two points - although the documentation states:
    "Action Executed" variable to "TRIGGUER"
    for the open case, it actually sets it to the american spelling: "TRIGGER".

    The second is more an item of interest that developers should be aware of. When the modal opens there is a close dialog icon [x] in the upper right hand corner. When the dialog is closed using the [x], then no boundary event is fired and the 'Action Executed' variable remains set to 'TRIGGER', so if you have any code that is associated with the CANCEL button, it will not run if the user closes the dialog with the [x].

  • Avatar
    Sergei Malynovskyi

    Thank you, Jay.
    Re point one - based on my conversation with Brazos UI dev team they believe that the spelling is still "TRIGGUER". They didn't want to change it because it would break existing implementations.

    Re point two - thank you, noted. DEV team is aware.

  • Avatar
    David Bailie

    Note that in Brazos UI v4.1.0 - 2015-08-02 an additional boundary event was added on closing the Modal via a background click, using the [x] or pressing Esc. From the release notes:

    [Improvement - US1715] [Modal]: Added Boundary Event for Modal Close (on background click, "x" button click, or Esc key press)

  • Avatar
    Matthew Corbett

    Great article. Very helpful to include the .twx.

  • Avatar
    Jay Rosenberg

    Brazos version 2.0 (5.4.6 Enterprise Edition - shows that the configuration option: Error Message on Return from "Done" Boundary Event

    is marked as Deprecated - and is in the Deprecated section.  Is there now a new recommended way to keep the Modal open if there are validation errors in the modal on Done?  Can the document be updated to include the new method as well?


  • Avatar
    Thomas Bushart

    Hi Jay,

    We'll work to bring the article up to date! In the meantime here's the summary of what you need to know:

    The Modal currently works within the existing validation framework, which is why the "Error Message on Return from "Done" Boundary Event" is no longer needed. Simply assign CoachValidation messages to controls in the modal as needed and it will remain open.


    Heritage Human Service
    For a HHS, the setup is as typical for validating a control. Configure the Modal to "Fire Boundary Event on Modal Done Button" and wire that event to where ever you need (script, service, or even just a stay-on-page). Change the boundary event to "Fire Validation: Before". From there, use a validation script as normal to set an error message on a control in the modal. As long as the validation fails and you add an error message to a control in the Modal it will not close on clicking the done button. Errors are displayed as typical for controls used in other containers.

    Client-Side Human Service
    Currently, the Modal's validation works in CSHS if you validate after coach exit. The "in coach" approach that leverages the Data Change script has some quirks that likely need to be addressed before I would recommend it with Modals (it works fine for other controls). The after-exit method is essentially the same as with HHS, it just doesn't have a built-in "Fire Validation: Before" option. But as long as the boundary event ends up returning a validation error to a control in the Modal it will not close when you click the Done button. See this IBM documentation on this CSHS validation style.

  • Avatar
    Thomas Bushart

    Article updated to reflect the latest behavior of the Modal in Brazos UI. Example application updated to show current validation methods of the Modal in both HHS and CSHS. Note: The example application has been updated to a base BPM version of 8.5.7 in order to properly illustrate validation within CSHS.

Please sign in to leave a comment.