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