In my Mendix application, I’ve added a new button, "Review Now", on the application detail screen. The button should only be visible to users with editor, infra, or admin permissions, as they can execute reviews for any application. When the "Review Now" button is clicked, I want to enforce the following validations: The Description field must contain at least 30 characters. The Resp IT Department must be a non-empty and valid IT department. The Resp IT Contact must be a non-empty and valid user. The System Type must be a non-empty and valid system type. The Business Criticality must be a non-empty and valid business criticality. If any validation fails, I need to display a meaningful error message explaining the reason for the failure. If all validations pass: The current date is stored in the Last Review Date field. The person performing the review is stored in the Last Review By field. All other changes made to the application are saved, and the screen is closed. Additional requirements: When a new application is created, the Review Date should default to the current date. Here’s the updated version of your question with the additional information: Title: How to Implement Button Validation and Permissions for a "Review Now" Feature in Mendix? Body:In my Mendix application, I’ve added a new button, "Review Now", on the application detail screen. The button should only be visible to users with editor, infra, or admin permissions, as they can execute reviews for any application. When the "Review Now" button is clicked, I want to enforce the following validations: The Description field must contain at least 30 characters. The Resp IT Department must be a non-empty and valid IT department. The Resp IT Contact must be a non-empty and valid user. The System Type must be a non-empty and valid system type. The Business Criticality must be a non-empty and valid business criticality. If any validation fails, I need to display a meaningful error message explaining the reason for the failure. If all validations pass: The current date is stored in the Last Review Date field. The person performing the review is stored in the Last Review By field. All other changes made to the application are saved, and the screen is closed. Additional requirements: When a new application is created, the Review Date should default to the current date. The review fields should also integrate with the Import/Export functionality and the API, maintaining the same validations and permissions for API updates. Current Implementation: I have already created a microflow to handle the validation of fields, which is working fine for the GUI. However, I need support in fulfilling the additional requirements: Executing the logic to save the review details and other changes made to the application when the validations succeed. I have attached a screenshot of my current microflow for reference How can I extend my microflow to handle saving the review details and closing the screen after successful validation? What is the best approach to reuse the same microflow logic for API calls (Create and Patch)? Any guidance, example configurations, or best practices would be greatly appreciated. Thanks in advance!
asked
Pushpendra Nayak
2 answers
1
Hi Pushpendra Nayak,
Create Subflow for Validation:
Develop a subflow that handles the validation logic.
Return a variable from the subflow to the parent flow.
Decision Check in Parent Flow:
Pass the returned variable from the subflow to a decision element in the parent flow.
The decision logic is based on the value of the returned variable.
Commit the Object:
After evaluating the validation flow, commit (save) the object to ensure any changes are persisted.
Make API Calls:
Once the validation is successful, proceed with the API calls as part of the process.
answered
Pragadeeswaran Sivakumar
0
For complex conditional visibility this marketplace module can still help: https://marketplace.mendix.com/link/component/2539 With this widget you can use a microflow or nanoflow to decide if something needs to be shown. In the flow you could check for the conditions to show the button.
On the button itself you can again use a microflow to do each of the validations. If you have multiple validations I would suggest to create one string where for each validation that fails add a message to the string and then continue all the other validation. Otherwise the user would only get the first validation error and not the possible other validation errors.
And in your already created flow if all the validations are passed you could either at the end do the changes and commit or use a seperate subflow for this so you could re-use that flow on other locations where those objects need to be committed.