Based on Mendix best practices https://docs.mendix.com/howto/general/dev-best-practices#3-4-3-page-based-microflows
ACR Rules
- Security (28)
- Access rules in multi-tenant apps should lead to CurrentUser
- Anonymous users should only be allowed to create non-persistent entities
- A project administrator should only be able to create administrative accounts
- A strong password policy should be set
- Constants should not be exposed to the client
- Demo users should be turned off
- Entity access default rights for new members should be None or Read
- Entity access rules should be using attributes/associations with at most read access in XPath constraints
- Hash Algorithm should be BCrypt or SSHA256
- If an anonymous user is allowed to change objects, constrain these objects to the owner
- Only “admin” roles should manage other users
- Only named/registered users should be allowed
- Project security must be checked
- Retracted Mendix versions should not be used
- Security should be enabled and set to Production
- Unlimited string attributes should not be editable by anonymous users
- User roles with a certain amount of module roles should be checked for security
- Access rules in multi-tenant apps should have an XPath constraint
- Always use the inherited entity to create records for System.FileDocument or System.Image
- Attribute widgets in data views should be editable
- Entity access should be applied when generating documents
- Microflow called from the client should apply entity access rules
- Microflow should only have permissions if used from a page
- Published Rest and Web services should require authentication
- Constants should not be used for sensitive information
- The default administrator name should be changed
- Users should be signed in with a maximum of one session
- Use user libraries without security vulnerabilities
- REST calls with templates should be escaped
- Page URL’s should be checked (Dec 2022)
- Reliability (41)
- Attributes should not be re-assigned in create/change object
- Chain of “if/else if” statements should have different conditions
- Check for empty string should be done properly
- Conditions should always include at least one variable
- Day of year should not be used in parse/format date time functions
- Delete behaviour should have error message if blue
- Empty variables should not be used in actions that throw null pointer exception
- Entity events should have either no or exactly one handler
- Entity validation rules should have an error message
- Events should be triggered when doing a commit
- Expressions for “then” and “else” in an “if” statement should be different
- Function arguments should be different
- Hour format should be specified correctly in parse/format date-time functions
- Identical expressions should not be used on both sides of a binary operator
- Lists operations should be passed different arguments
- Lists should not be modified during iteration
- MM and mm tokens should be used correctly in parse/format date-time functions
- Objects should not be dereferenced after failing an empty check
- Only non-empty objects should be dereferenced
- Only variables that are not empty should be returned or assigned
- REST/Web service should have custom error handling
- REST/Web services should have a timeout
- Seconds token should be specified correctly in parse/format date-time functions
- Short-circuit logic should be used correctly to prevent null pointer dereferences in conditionals
- Substring function invocation should make sense
- System.User and System.Session objects should not be created directly
- Variables should not be indirectly compared to empty
- Week year should not be used in date formatting or parsing
- Associations should specify a delete behaviour
- Check for negative conditions in XPath should be done using not instead of !=
- Declared variables should be used
- Imported data should be committed or stored in a variable
- Return expressions for a flow should be different
- Type parameters in a java/script action should be used
- Variable CurrentUser should only be used in a user context
- Variables should not be self-assigned
- Microflow should allow concurrent access
- Module roles should be assigned to a project/user role
- Returned variables should be used
- AM/PM indicator should only be used in combination with lowercase “h”
- Prevent duplicate classes in jars
- Performance (29)
- Calculated attributes should only have fast actions
- Commit entities in the same order in different microflows to prevent deadlock
- Commits should take place outside of a loop
- Dropdown reference selectors should be used sparingly
- Entity should have a maximum of N calculated attributes
- Project role should have at most one module role per module
- Event handler after event should have fast action
- Event handler before event should have fast actions
- Page button synchronous microflows should only have fast actions
- Page data source microflows should only have fast actions
- Page on change microflows should only have fast actions
- Page widget microflows should only have fast actions
- Checking for empty on associations should be done without retrieving
- Scheduled events should be executed with reasonable delay
- Entity should have a maximum of N indices
- Entity should have a maximum of N reference set associations
- Many-to-many associations should have owner “Default”
- Microflow retrieve from database and aggregate should be adjacent
- Microflow should not apply entity access
- Microflows should perform database actions at the end
- Not/or expressions in XPath should be avoided when the path goes over an association
- Only short actions should be used in a loop
- Positive conditions should be preferred when retrieving data
- Retrieve & aggregate combo should not be nullified by using the list
- Retrieves over the same association should be grouped together
- Loops should not have loops inside
- Persistent entities should have indices
- Keep the number of index columns low
- The Uniqueness Validation should be set to Database
- Architecture (16)
- App store modules should be unchanged (preview)
- App store modules should use the latest version (preview)
- App store widgets should be unchanged (preview)
- App store widgets should use the latest version (preview)
- Associations should only rarely be cross-module
- Entities should not be associated with a system enty
- Entities should not inherit from Administration.Account
- Entities should not inherit from a system entity
- Inheritance should be limited to 2 levels
- Microflow should be simple (cyclomatic complexity)
- Microflow should be simple (CLEVR complexity)
- Microflow should not have loops in the flow
- Microflows should not call themselves
- Microflows should only rarely call microflows from other modules
- Minimize the use of self-relations
- Retrieve by association from persistent to non-persistent is not advised
- Maintainability (28)
- Actions in a flow should be different
- Custom error handling should be logged
- Custom error handling should not be “Continue”
- Entity should have a maximum of N access rules
- Expressions should be simple
- Module should have a maximum of N security roles
- The latest Mendix version should be used
- URL endpoints should not be hard-coded
- Entity should have a maximum of N associations
- Entity should have a maximum of N attributes
- Entity should have a maximum of N event handlers
- Entity should have a maximum of N non-required validation rules
- Entity should have a maximum of N validation rules
- Exclusive split should have a descriptive caption
- Log message nodes should be consistent
- Microflows should be simple or be documented
- Microflow should have a maximum of N actions
- Microflow should have a maximum of N annotations
- Microflow should have a maximum of N ends
- Microflow should have a maximum of N loops
- Microflow should have a maximum of N merges
- Microflow should have a maximum of N parameters
- Microflow should have a maximum of N splits
- Module should have a maximum of N entities
- Module should have a maximum of N flows
- Styling should be done using sass
- Project should have a maximum of N user libraries
- Project should have a maximum of N widgets
- Project hygiene (32)
- Actions should use the default color
- After startup project microflow should be named properly
- Associations should contain the name of the associated entities
- Attributes names should not start with their entity name
- Before shutdown project microflow should be named properly
- Calculated attribute microflows should be prefixed correctly
- Complex pages should have documentation
- Complex microflows should have documentation
- Documents in a module should be organized in a good folder structure
- Entity names should be unique across the project
- Enumerations should be prefixed correctly
- Event handlers should be prefixed properly
- Flows should only be modeled to the right and downwards
- Flows without permissions should be prefixed properly
- Folders should contain at least one document
- Folders should contains only a small number of documents
- Folder structure should not be too deep
- Health check project microflow should be named properly
- Large entities should have documentation
- Layouts should be prefixed properly
- Microflows called from pages should have a name based on the trigger event
- Microflows called from published services should be prefixed correctly
- Microflows name should be based on the object it is operating on
- Module should have a maximum of N excluded items
- Only folders should be the direct children of a module
- (Removed) Postfix on enumeration
- Project navigation microflow should be named properly
- Project should have a maximum of N modules
- Scheduled event microflows should be prefixed correctly
- Snippets should be prefixed properly
- Sub-microflows should be prefixed correctly
- Sub-Microflows that are used in Nanoflows should be prefixed properly
- There should be no ToDo annotations in the project
- Home
- Docs
- ACR Rules
- Project hygiene (32)
- Microflows called from pages should have a name based on the trigger event