Released 18th of August 2021.

We are back! It has been a long time since our latest release. Due to holidays and some dependencies, we did not see an opportunity to release earlier. But hey, that means this one is jam-packed with awesome stuff😎

This release will introduce not one, not two, ‘are they joking??’, but three significant features and many improvements. So bear with us while we walk through them. #Excited

We understand you might not want to read everything, so you find a summary of this release below.

Significant features

• The new Enterprise Licensing will slowly be rolled out to customers. You can request to add apps to ACR from within the product. #NoMoreEmails
• We introduce the Java Libraries feature to give you insight into whether Jar files inside your application contain potential security vulnerabilities or duplicate classes. #SecurityAndMaintainability👍
• We introduce Annotations, a powerful new way to allowlist violations directly from within your model. #PowerToTheMxDev

Smaller changes

• We now support Mendix applications up to Mendix 9.4. #PowerToTheInnovaters
• The SMART Digital Factory now remembers what tool you were using for what application the last you visited! #PowerfulDelighter #ALotLessClicking

“They are more like guidelines than actual rules.” #ThisIsWhatWeDo😎

• Improved many, many, rules. We improved the underlying algorithms to find more violations or fix issues with false positives.
• Introduced six new rules.
• Rule change impact analysis.

We also did a bug smash.

These changes have an impact on the number of violations that are in your application. They might become less, or new violations are found. We added a description of a test project to show you how your application might be impacted. In addition, the details under the rules section show what we changed and which rules are affected. 

Below you find a more elaborate explanation of what we changed and even why we changed it. We hope you take the time to read it. 

We hope you enjoy this new release as much as we enjoyed building it. Would you please let us know if you have any feedback? We greatly appreciate it. 

With great pride and warm regards, 

The CLEVR Tooling product team

Significant features

Enterprise licensing

After a successful beta, we can finally introduce our improved licensing system to our other customers. The new enterprise license enables users to request licenses from within ACR, so no emails with app ID to our support department. Each customer appoints license admins who can approve or deny the requests. 

The enterprise licensing will make it much easier for end-users to enable ACR for their Mendix apps, and our support team has more time available to solve customer problems. Thanks for the patience, CLEVR Support. You rock! 

We will gradually roll out the new licensing to our customers. 

For more information, visit the documentation. We are working on updating these.

Java Libraries

We talk to many experienced Mendix developers daily, and we even are experienced Mendix developers ourselves. Many times the issues with java dependency in Mendix came up. In short, you can extend the Mendix platform with Java code. In many cases, the Java code will leverage existing Java Libraries (Jars). When you download an App Store module with custom Java (almost all modules have this), you also download the Jar files used by the module. These Jars create risks from a maintainability and security perspective. That is why we decided to tackle the problem. 

With great pride, we introduce the Java Libraries feature in ACR! 

The Java Libraries feature solves two common issues Mendix developers encounter. 

Potential security risks

Most jar files are created and maintained by third parties and are used as a library of various methods and calls. Over time many vulnerabilities are discovered and fixed in these libraries. If a Java action uses the jar during runtime, such a security vulnerability could cause serious harm to the security of your Mendix application. Good to know that not all vulnerabilities are exploitable. The library’s issues might be in a part that is not executable from your application because it is not exposed through a Java Action or the Java action is not used in your app. 

The Java Libraries feature reviews the jar files against the NIST database for security vulnerabilities to give you insight into your Jar files’ security risks.

With the Java Libraries feature, we enable Mendix developers to remove potential security risks and improve the overall security of their Mendix application. 

The runtime classloader issue 

If you have multiple jar files with the same class, Mendix will pick one during the runtime. However, if it chooses the wrong version, your app can crash. The only way to avoid this is to ensure that you have only one jar file in the userlib that contains the specific class. The best way of figuring out which jars have duplicate classes is a time-consuming, trial and error method with a bit of luck. The Java Libraries feature shows you what Jars have identical classes and where they are located. 

With the Java Libraries feature, we enable Mendix developers to remove redundant jar files and reduce the risks of applications hanging or crashing, improving the overall maintainability of your Mendix application.

For more information, visit the documentation. We are working on adding them to the website.

Annotations

Sometimes a minor issue can turn into a new feature: we proudly present Annotations! We love to give you some insight into our way of thinking. Below is the story of where we started and how we got to the Annotations.

In the past, you might have noticed that adding one violation to the allowlist removed multiple violations from the violation list. 

The investigation into adding a violation to the allowlist showed us that not all violations were uniquely identifiable (aka we saw duplicate keys that were supposed to be unique). We decided to take a second look at every rule and see if the right level of uniqueness is used. If a violation can occur multiple times in a microflow, it should be reported per action. On the other hand, if a violation can happen numerous times per action, for example, in an expression, and we cannot uniquely refer to that expression, we decided to combine multiple expression violations into one violation per microflow action.

Thinking through the allowlist and the uniqueness of violations further and looking at how high code languages solve this, we decided to introduce annotations in the model. 

Introducing annotations started straightforward, but ACR must still show what was allowed. So, violations that are annotated must go to ACR, marked as allowed. This is, in most cases, simple. However, we have several rules that did stop checks on the first occurrence. For example, the ‘must use fast action’ rule. The tricky part is what to send to ACR if the first heavy (not fast) action is annotated… This lead to a redesign of several rules to report on all occurrences of the violation.

Needless to say, a few months further, we believe we significantly improved ACR with good unique violations, annotations in the model, and some improved rule algorithms. The result, however, means that the number of violations generated will change. But we will elaborate on that further down.

We use the annotation to tag the ‘code’ and let ACR know that it is allowed. Now we no longer need a unique identifier. 

But the best part? We integrated further in Studio Pro, where the magic happens and the primary workplace of every Mendix developer. Even if you decide that you do not want to use ACR anymore, you still have all your allow listing in your Mendix model. We do not believe in Vendor Lock-In. We want you to keep using ACR because you feel empowered in your work when using it. #PowerToTheMxDev 

“They are more like guidelines than actual rules.” #ThisIsWhatWeDo😎

Rule improvements

FlowWalker rules

We have an algorithm that is used to step- or walk through a microflow. This algorithm is improved to walk into rule-splits, domain model events, and, on occasion, calculated attributes. 

Rules dependent on the FlowWalker are thus enhanced and could report more violations. FlowWalker rules are:

• Custom error handling should be logged.
• Microflow retrieve from database and aggregate should be adjacent.
• Only non-empty objects should be dereferenced.
• Microflows should perform database actions at the end.
• Variable CurrentUser should only be used in a user context.
• Commits should take place outside of a loop
• Only short actions should be used in a loop.
• Loops should not have loops inside.
• Checking for empty on associations should be done without retrieving.
• Return expressions for a flow should be different.
• Microflows should not call themselves.
• Commit entities in the same order in different microflows to prevent deadlock.
• Only variables that are not empty should be returned or assigned.
• Variable should not be indirectly compared to empty.
• Empty variables should not be used in actions that throw null pointer exception.

Fast action rules

Fast actions were reported per microflow action on the main microflow. Sub-microflows were reported on the call microflow action.

Fast action rules occur in several places: event handlers, calculated attributes, page events, microflow loops. The violations’ uniqueness now depends on the origin and not the heavy (not fast) action in the microflow.

• Event handler before event should have fast actions.
• Event handler after event should have fast actions.
• Page data source microflows should have fast actions.
• Page on change microflows should have fast actions.
• Page button synchronous microflows should have fast actions.
• Page widget microflows should have fast actions.
• Calculated attributes should have fast actions.

Expression rules

Many rules check expressions. Violations were reported per expression and are now reported per microflow action where the expression is used.

• Expressions should be simple.
• Expressions for “then” and “else” in an “if” statement should be different.
• Identical expressions should not be used on both sides of a binary operator.
• Chain of “if/else if” statements should have different conditions.
• Check for empty string should be done properly.
• Week year should not be used for date formating/parsing.
• Objects should not be dereferenced after failing an empty check.
• Substring function invocation should make sense.
• Function arguments should be different.
• Variable should not be indirectly compared to empty.
• Return expressions for a flow should be different.
• Hour format should be specified correctly in parse/format date-time functions
• AM/PM indicator should only be used in combination with lowercase “h”.
• Not/or expressions in XPath should be avoided when the path goes over an association.
• Retrieves over the same association should be grouped together
• Check for negative conditions in XPath should be done using not instead of !=.
• Short circuit logic should be used correctly to guard against dereference of empty variables.
• Only variables that are not empty should be returned or assigned.
• Day of year should not be used in parse/format date time functions
• MM and mm tokens should be used correctly in parse/format date-time functions.
• Seconds token should be specified correctly in parse/format date-time functions.
• Conditions should always include at least one variable.
  

Other rule changes

Sub-microflows should be prefixed correctly.

Rule redesigned to report per microflow instead of per ‘used by object’ where the name conflicted.

Documents in a module should be organized in a good folder structure

Rule redesigned to report per module as not all the possible violations have a unique identifier.

Exclusive split should have a descriptive caption.

Made unique per split instead of per microflow.

Entity access rules should be using attributes/associations with at most read access in XPath constraints.

Rule algorithm improved to handle inheritance.

Objects in the system module should not be created directly or changed.

Rule extended to not allow changes either, except for User, Image, and FileDocument.

New rules

• Always use the inherited entity to create records in System.FileDocument or System.Image
• Use user libraries without security vulnerabilities
• Prevent duplicate classes in jars
• Project should have a maximum of N widgets
• Project should have a maximum of N user libraries
• Attributes within a data view should be editable.

Bugfixes

• rule SecurityAvoidSystemFileDocument bugfix protect against null on entities from AppServices
• rule MicroflowActionRetrieveByAssociationPersistentToNonPersistent protect against null on entities from AppServices
• rule SecurityEntityAccessXpath handle System.owner and System.changedBy
• rule SecurityEntityAccessXpath handle type ‘Both’ association where cross-module uses entity name instead of id
• fix created variables empty error from logs where they were ‘Nothing’ aka void type

Comparing the number of violations before and after release 2.6

We investigated the consequences for several apps, comparing the exact same model with the previous and the current release of ACR. In all cases, we saw a decrease in the total amount of violations by 10% – 15%.

For a very large monolithic app with 45000+ violations:

Rule	Diff (minus is less violations)	Remark
Sub-microflows should be prefixed correctly	-5655	Made unique. Was per ‘used by object’, now per microflow
Not/or expressions in XPath should be avoided when the path goes over an association	-738	Unique per node instead of (part of) expression
Documents in a module should be organized in a good folder structure	-364	Unique per module
Page button synchronous microflows should have fast actions	-167	Unique per widget instead of per microflow heavy action
Page widget microflows should have fast actions	-140	Unique per widget instead of per microflow heavy action
Event handler before event should have fast actions	-92	Unique per event handler instead of per heavy action in the called microflow
Expressions should be simple	-47	Unique per node instead of (part of) expression
Page data source microflows should have fast actions	-45	Unique per widget instead of per microflow heavy action
Short circuit logic should be used correctly to guard against dereference of empty variables	-16	FlowWalker improved
Page on change microflows should have fast actions	-12	Unique per widget instead of per microflow heavy action
Folders should contains only a small number of documents	-9	Uniqueness
Event handler after event should have fast actions	-6	Unique per event handler instead of per heavy action in the called microflow
Check for empty string should be done properly	-5	FlowWalker
Declared variables should be used	-5	FlowWalker
Calculated attributes should have fast actions	-2	Unique per attribute instead of per microflow heavy action
Check for negative conditions in XPath should be done using not instead of !=	-1
Published service operation microflows should be prefixed correctly	-1
Microflow should have a maximum of N splits	1
Microflow should not have loops in the flow	1
User roles with a certain amount of module roles should be checked for security	1
Checking for empty on associations should be done without retrieving	2
Persistent retrieve by association action should retrieve persistent other entity	3
Project role should have at most one module role per module	3	Uniqueness
Variable CurrentUser should only be used in a user context	3	Do not stop on first occurrence
Actions in a flow should be different	4
Microflow should have a maximum of N actions	4	Bugfix
Microflow should be simple cyclomatic complexity	5
Returned variables should be used	5	FlowWalker
Folder should contain at least one document	7	Excluded disabled documents
Microflow should be simple CLEVR complexity	9	FlowWalker improved
Commits should take place outside of a loop	12	Unique per action
Microflows called from pages should have a name based on the trigger event	13	Unique per widget instead of per microflow
Only short actions should be used in a loop	19	Heavy actions unique per action instead of per microflow
Microflows should not call themselves	23	FlowWalker improved
Entities should not be associated with a system entity	26	NEW
Events should be triggered when doing a commit	50	Modified, annotation setting removed
Microflows should perform database actions at the end	56	Unique per commit node instead of per microflow
Entity names should be unique across the project	57	Made unique
Entity access rules should be using attributes/associations with at most read access in XPath constraints	298	Rule improved
Exclusive split should have a descriptive caption	331	Unique per split instead of microflow