Validation not refreshing when navigating interfaces

Hello All,

I have an issue wherein my validationMessage is not removing after clicking cancel button. My scenario is I have a User Form that whenever I click submit it will show a message "All fields are required". After that I will now click the Cancel Button. However, when I go back to the Form my validation is still there. Can anyone explain to me how can I prevent that from happening?

Here's my validation

a!validationMessage(
message: "You must fill up both roles and email address!",
validateAfter: "SUBMIT",
showWhen: or(isnull(local!email), isnull(local!role))
)

Here's my field

a!textField(
label: "Email",
labelPosition: "ABOVE",
value: local!email,
saveInto: local!email,
refreshAfter: "UNFOCUS",
validations: {}
)

I put the validationMessage under the columnLayout.

  Discussion posts and replies are publicly visible

Parents
  • +1
    Certified Lead Developer
    in reply to rainier_albario

    After any validation has been triggered for a particular instance of a form, it will stay triggered until the form is exited (like via a submit button click).  If you want your user to be able to press "cancel" and go back to a default state, you should have the cancel click submit from the current form and chain the user into a new instance of the same task - to the user this will happen seamlessly.

    If the task in question is a start form, then it's a little trickier, but should still be possible - i.e. have the "cancel" button start the process then chain the user into a User Input Task that has the same interface set as its form.  Honestly though at this point you may as well ditch the Start Form setup and instead just have the process contain that task, and an XOR gateway could check what button was clicked and if it was "cancel", loop the user back to the same form again, otherwise move on in the process.

Reply
  • +1
    Certified Lead Developer
    in reply to rainier_albario

    After any validation has been triggered for a particular instance of a form, it will stay triggered until the form is exited (like via a submit button click).  If you want your user to be able to press "cancel" and go back to a default state, you should have the cancel click submit from the current form and chain the user into a new instance of the same task - to the user this will happen seamlessly.

    If the task in question is a start form, then it's a little trickier, but should still be possible - i.e. have the "cancel" button start the process then chain the user into a User Input Task that has the same interface set as its form.  Honestly though at this point you may as well ditch the Start Form setup and instead just have the process contain that task, and an XOR gateway could check what button was clicked and if it was "cancel", loop the user back to the same form again, otherwise move on in the process.

Children