If ACR generates a violation and you decide in this case the violation is allowed, as designed, a needed exception or any other good reason to allow this, you have 2 options:
- Add the violation to the allow list
- Annotate the violation in the model
Both options remove the violation by default out of the list of violations. Both options can show the allowed violations by filtering them:
The advantage of annotations is that the annotation is in the model and visible for the developer.
Allowlist
A violation can be added to the allowlist from the violations overview.
In the allowlist tab, you can see 4 different ways in which violations can be allowed:
- Modules from the Appstore can be automatically be put on the allowlist
- Individual modules can be placed on the allowlist via the modules menu
- Violations can be annotated in the model. Here the number of violations annotated in the model is shown. The violations themselves can be found under the violations menu when searching for allowlisted violations. This is because these violations are per revision and the allowlist is independent of revisions.
- Allowlisted violations in this project.
To filter violations in the allowlist:
To remove one or more violations from the allowlist, select the specific violations or rule(s) and click on Unlist selected.
Annotations
Violations can be annotated in the model. For this you need a code. The annotation is prefixed with ‘/*ACR-Allow:’. Next, the short rule code is added. The code annotation can contain multiple rules, separated by a comma, semi-colon, dot or space. The code annotation ends with a ‘*/’, so you can still add other text to the documentation.
The code comment syntax /* … */ has been chosen because widgets do not have a documentation property and we want to annotated them via the style property. The comment syntax makes sure our annotation does not interfere with styling.
You can add other text to the documentation before or after the annotation. You can add multiple annotations.
This short rule code can be found via the violation in the violations overview:
And via the rule settings details dialog:
Both copy the code for the annotation in the copy-paste buffer. So in the modeler in the right place you can paste this code.
Annotations in the model
Annotations in the model are placed in the following properties of the Mendix model:
- Documentation
- Microflow annotation for microflow actions
- Widget style for widgets
- As a simple document (a regex is chosen) in a folder for folder rules
Documentation property
All documents and also entities, associations, attributes, module roles, project roles have a documentation property. Hence the documentation property is the default place to add code annotations.
Microflows
In microflows, you can add visual text annotations. In this text we can add a code annotation:
Widgets
In widgets adding annotations is harder, but we can choose the style property to add a code annotation:
Folders
For folders we can add a regular expression:
This also works for modules, when placed in the root of the module. The name of the regular expression does not matter. We scan all regular expressions for annotations.
We chose not the use a disabled regular expression because you want to be able to search for ‘/*ACR’ in the model and disabled documents are skipped in the search!!
Documents without documentation property
For documents without a documentation property (like an enum) you can use the allowlist.
Project
For the entire project, there is no good place to annotate. Use the allowlist.