We should improve the "lane" error message by guiding the user to the lane. Currently, the message references the process.

• lint extension elements
• lint extension element properties
• lint references

Full list of errors can be found here: https://github.com/bpmn-io/internal-docs/issues/435

Child of https://github.com/bpmn-io/internal-docs/issues/430

The escalation-reference rule always requires an escalation reference even though no reference is required for escalation boundary events.

There is an existing rule (inclusive-gateway) that checks sequence flow conditions. However, this rule only checks inclusive gateways.

According to the implementation of Zeebe the rules are:

Sequence Flow

• must have condition of be default sequence flow

Exclusive Gateway

• default flow must not have condition
  • this is probably a bug cf. camunda/zeebe#10310 (comment)
  • bpmn-js actually prevents this cf. https://github.com/bpmn-io/bpmn-js/blob/develop/lib/features/modeling/behavior/ReplaceConnectionBehavior.js#L151
• default flow source must be gateway (seems like due to the implementation this can never not be the case 🤡 cf. https://github.com/camunda/zeebe/blob/clients/go/v8.1.3/bpmn-model/src/main/java/io/camunda/zeebe/model/bpmn/validation/zeebe/ExclusiveGatewayValidator.java#L41)

Inclusive Gateway

• default flow source must be gateway (seems like due to the implementation this can never not be the case 🤡 cf. https://github.com/camunda/zeebe/blob/clients/go/v8.1.3/bpmn-model/src/main/java/io/camunda/zeebe/model/bpmn/validation/zeebe/InclusiveGatewayValidator.java#L38)

Related to camunda/camunda-modeler#3157

Validation of link events was introduced with #62. Since Zeebe doesn't validate that catching and throwing events are children of the same process, we don't validate it either. Once Zeebe adds validation, we'd want to follow up.

Related to camunda/zeebe#14028
Follow-up to #62

Escalation boundary events are only supported on elements that spawn a child instance. The following case should be marked as not supported as deployment will be rejected:

Validation of link events was introduced with #62. Zeebe validates that for a throwing link event there is a catching link event with the corresponding name. The link-event rule should validate this, too.

Follow-up to #62

Lint rules for expressions:

Child of #7

Camunda 8.3 supports two different types of forms:

• embedded through formKey
• linked through formId

These two are exclusive. formId is not supported by older versions of Camunda 8. Linting should indicate that.

Related to camunda/camunda-modeler#3656

The feel rule matches any property that starts with = regardless of whether this property can be a FEEL expression.

<bpmn:serviceTask name="==5" />

will lead to a report that name is not a valid feel expression.

A possible solution could be adding metadata to the camunda-bpmn-moddle extension.

Example:

{
  "name": "InputOutputParameter",
  "properties": [
    {
      "name": "name",
      "isAttr": true,
      "type": "String"
    },
    {
      "name": "value",
      "isBody": true,
      "type": "String",
      "meta": {
        "feel": true
      }
    },
    {
      "name": "definition",
      "type": "InputOutputParameterDefinition"
    }
  ]
},

We'll have to investigate whether this works for all FEEL properties. Alternatively, we could have a list of properties that are supposed to be linted.

Camunda Platform is Camunda now.

https://github.com/search?q=repo%3Acamunda%2Fbpmnlint-plugin-camunda-compat%20platform&type=code

zeebe:candidateUsers is only supported by Camunda 8.2 or newer.

Related to camunda/camunda-modeler#3385

zeebe:TaskSchedule extension elements supported by Camunda 8.2 will be validated by the engine. Both dueDate and followUpDate will be validated to be either valid FEEL expressions or valid ISO 8601 DateTime strings. zeebe:TaskSchedule extension elements are only allowed by Camunda 8.2 and newer.

<userTask id="UserTask_1">
    <extensionElements>
        <zeebe:taskSchedule dueDate="2023-04-20T04:20:00Z" followUpDate="=followUpDate" />
    </extensionElements>
</userTask>

Requires camunda/zeebe-bpmn-moddle#45
Related to camunda/camunda-modeler#3484

What should we do?

• Mark elements that are not supported for execution in C8 as incompatible

Why should we do it?

As decided we want to allow our users to model all BPMN elements in C8 diagrams and resort to linting to identify incompatible (for execution) elements.

The rule should detect the following modeling patterns

In order to prevent hard-to-debug runtime errors Zeebe will introduce loop detection (cf. camunda/zeebe#13025). The linter should be able to detect loops so they can be fixed before deployment.

How does the rule improve the BPMN diagram?

Loops are detected and can be fixed.

Rule Details

• Name: no-loop
• Default notification level: error

The new generic extension point is supported in Camunda Platform v8.1+.

As of version 0.7, there is no recommended config exported anymore. So instead of plugin:camunda-compat/recommended you would have to use plugin:camunda-compat/camunda-cloud-8-0 or something similar.

It would also be great to have a migration guide how we can achieve a behavior similar to the previous recommended settings with version 0.7

Camunda 8.2 supports link events. We should introduce lint rule(s) that support the user in using the link event correctly.

• require the name property to be set on both catching and throwing link events
• validate that there isn't more than one catching link event with the same name
• validate that catching and throwing events are children of the same process (Link
  Event uses are limited to a single Process level (i.e., they cannot link a
  parent Process with a Sub-Process)) Zeebe doesn't validate this either

Reported via https://camunda.slack.com/archives/CKGH9LR40/p1668781530507669

This needs to be fixed at https://github.com/camunda/bpmnlint-plugin-camunda-compat/blob/main/rules/utils/iso8601.js#L12

• For Camunda 8.2+, require to set either script or task headers on ScriptTask
• For previous versions, disallow script usage

I missed that https://github.com/camunda/product-hub/issues/698 is only about throw events. We should not allow expressions for these events only and ignore values starting with = for catch events.

Rules for mandatory presence of extension elements:

Child of #7

Rules for mandatory element attributes and attribute validation:

Attributes

Child of #7

Check out this test case: https://github.com/camunda/bpmnlint-plugin-camunda-compat/tree/timer-cycle-not-validated-anymore

We don't validate whether cron is supported for time cycle.

• simplify architecture
• compose based on config instead of rule

Related to https://github.com/bpmn-io/internal-docs/issues/517

secrets.FOO produces a lint error stating that the secret expression is not valid. In fact, this format is currently supported but will be deprecated in the future. Therefore the lint error should be a warning instead. The message should indicate the future deprecation and the new format ({{secrets.FOO}}).

Follow-up to #119

With camunda/zeebe#13959, Zeebe introduces a new property CalledElement#propagateAllParentVariables. This property gets available with 8.2.x, and 8.3. Note: The property gets backported to 8.2 and made available with an 8.2.x patch release.

• allow connectors (element templates) for Camunda 8
• disallow connectors (element templates) for Camunda 8 (Zeebe 1.0, 1.1 and 1.3)

The assumption is that connectors are synonymous with element templates (modeler:template attribute).

Depends on #29
Related to https://github.com/camunda/web-modeler/issues/1246

The rule should detect the following modeling patterns

Incorrect: Camunda 8.1 will reject this:
converted-c8-conditional-flow.bpmn.txt

'converted-c8-conditional-flow.bpmn': - Element: DoSomethingTask
    - ERROR: Conditional sequence flows are only supported at exclusive or inclusive gateway

Correct: Camunda 8.1 will accept this:
converted-c8-inclusive-gateway.bpmn.txt

In addition, we consider modeling implicit gateways a bad practice, so even if zeebe will support conditional flows, this rule would still apply as warning or info.

How does the rule improve the BPMN diagram?

This rule will prevent users from creating undeployable diagrams.

Rule Details

• Name: no-conditional-flows
• Default notification level: error

What alternatives did you consider?

Camunda 8.3 is going to support signal intermediate throw and end events.

• add Camunda 8.3 config
• adjust element-type configuration to support signal intermediate throw and end events in Camunda 8.3
• add signal-reference rule to lint signal reference and name

Related to camunda/camunda-modeler#3555

What should we do?

When a user links a form (via formId) to a user task or start event, no lint error should be thrown when checking against a Zeebe version lower than 8.4 in Web Modeler.

Why should we do it?

For Web Modeler, we'll implement a mechanism where linked forms will automatically be converted to embedded forms when deploying to a cluster version lower than 8.4 (see camunda/web-modeler#6603 and camunda/web-modeler#6723). Displaying a lint error to the user in this case would be confusing as it could create the impression that deploying a BPMN diagram with linked forms to Zeebe < 8.4 would not work.

In Desktop Modeler, the lint rule for checking linked forms (implemented in #144) should still throw an error though as no automatic conversion mechanism exists.

This means the following combinations should throw lint errors (:x:) or pass the linter (✅) in Web Modeler:

Acceptance Criteria

• https://github.com/camunda/web-modeler/blob/15a2ea4e49f8bee6db4c235df6d3deb062fcb16b/webapp/src/App/Pages/Diagram/Publication/publicationPropertiesGroupExtension/FormGroup/StartEventFormLintRule.js is moved to the core
• no linting error for Web Modeler is raised for Web Modeler when a form is linked to a user task or start event and checking against Zeebe < 8.4
• a linting error for Web Modeler is raised when linking a form to a start event and checking against Zeebe < 8.3 (same as for embedded forms)
• a linting error is raised when both a formKey and a formId are defined on a start event or user task - the form types are mutually exclusive

Definition of Ready - Checklist

• the issue has a meaningful title, description and testable acceptance criteria
• edge cases and limitations are clear
• unclear requirements have been broken down into separate issues (always make progress)

When the user deletes the name of a global reference, the click on the linting message does not focus and mark the related input.

See comment in linting PR

Related to camunda/camunda-modeler#3319

• validate time expression type is supported
• support time date expression type for timer intermediate catch and boundary events in Camunda 8.3

Related to camunda/camunda-modeler#3516

Using the same name for two throwing link events should be discouraged as it is equivalent to an implicit join. There should be a 1:1 relationship between all throwing and catching link events.

Problem

We already had multiple cases where deployments to Camunda failed or went to unexpected results, because of missing bpmndi info.

See:

• https://camunda.slack.com/archives/C034N0E5YCX/p1654165797392569
• https://jira.camunda.com/plugins/servlet/samlsso?redirectTo=%2Fbrowse%2FSUPPORT-9121

Solution proposal

The no-bpmndi rule detects such cases: https://github.com/bpmn-io/bpmnlint/blob/master/rules/no-bpmndi.js. We could easily include it in our standard camunda-compat ruleset. It also fits well, since it ensures, that the diagram can successfully be deployed to Camunda.

Hi! I try to use youre plugin with bpmnlint, for validate my bpmn xml files.
I run "npm install [email protected]"
I am exporting xml from camunda modeler desktop, writing for 8.0.0.
My .bpmnlintrc file:

{
  "extends": [
    "bpmnlint:recommended",
    "plugin:camunda-compat/camunda-cloud-8-0"
  ],
  "rules": {
    "label-required": "off"
  }
}

After i run: bpmnlint file_name.bpmn, i get:

Activity_0xo3d6b error Element of type bpmn:ServiceTask must have one extension element of type zeebe:TaskDefinition calculate action [product action calculator]
Activity_0vdvlk5 error Element of type bpmn:ServiceTask must have one extension element of type zeebe:TaskDefinition calculate action [product action calculator]
Activity_0oq172q error Element of type bpmn:ServiceTask must have one extension element of type zeebe:TaskDefinition calculate action [product action calculator]
Activity_1w1cci3 error Element of type bpmn:CallActivity must have one extension element of type zeebe:CalledElement fulfill product action

But all types include in file, for example:
zeebe:calledElement:

<bpmn:callActivity id="Activity_1w1cci3" name="fulfill product action">
      <bpmn:extensionElements>
         <zeebe:calledElement processId="ProductFulfillment" propagateAllChildVariables="false" />
         <zeebe:ioMapping>
            <zeebe:input source="=productAction" target="productAction" />
         </zeebe:ioMapping>
      </bpmn:extensionElements>
      <bpmn:incoming>Flow_0c05f1n</bpmn:incoming>
      <bpmn:outgoing>Flow_0krmk5r</bpmn:outgoing>
</bpmn:callActivity>

zeebe:TaskDefinition:

<bpmn:serviceTask id="Activity_0xo3d6b" name="calculate action [product action calculator]">
      <bpmn:extensionElements>
        <zeebe:taskDefinition type="http" retries="3" />
        <zeebe:ioMapping>
            <zeebe:input source="=productEvent.productId" target="body.product.id" />
            <zeebe:output source="=body" target="productAction" />
        </zeebe:ioMapping>
        <zeebe:taskHeaders>
            <zeebe:header key="method" value="POST" />
            <zeebe:header key="url" value="{{PUBLIC_URL}}/productActionCalculator/calculateActionBySubscriptionTerminatedEvent" />
        </zeebe:taskHeaders>
</bpmn:extensionElements>

What i do wrong? I run on node 18, macOs 12.1 (Monterey)

Child of #7

Rules related to mandatory child elements:

Child of #7

Problem

Currently, a missing form is marked as an error. However, one can still deploy a diagram to Camunda 8.4.1 (this one I checked) even if a form is not defined. Moreover, there is a use case for such underimplemented form as reported by @NPDeehan in https://camunda.slack.com/archives/C0693F1NFK5/p1706613498853189.

Expected behavior

The linting rule should report a warning as we still want to encourage the users to define forms, but don't want to overreact as deployment can still succeed if form is missing.

What

Ensure eslint bpmnio plugin works correctly in this repo

Why

Apparently our eslint linting rules are not applied here. See: #15 (comment)

Originally reported by @till-stadtler in bpmn-io/bpmnlint#120.

The rule should detect the following modeling patterns

Conditions on outgoing sequence flows should always contain at least one process variable. If these conditions do not contain any process variable (dummy condition), they always evaluate to the same value.

If this value is false, the outgoing sequence flow will never be taken. This should be highlighted.

If this value is true:

• in XOR gateways: this sequence flow will always be taken, and an incident might be thrown if another outgoing sequence flow evaluates to true as well
• in OR gateways: in this case, the OR gateway should be replaced with the combination of a parallel gateway and another XOR/OR gateway to improve readability

If the dummy condition evaluates to false, this rule highlights that a certain path can never be taken.
If the dummy condition evaluates to true, this rule helps to avoid an incident arising or suggests a helpful refactoring.

Without the rule, BPMN models will continue to include dummy conditions on sequence flows behind OR/XOR gateways.

How does the rule improve the BPMN diagram?

Without the rule, BPMN models will continue to include dummy conditions on sequence flows behind OR/XOR gateways.

Rule Details

• Name: no-dummy-conditions / static-expression
• Default notification level: warn

The no-loop rule aims to detect potential loops. These can also include call activities. If a call activity calls its parent process, it can cause an endless loop. The no-loop rule mirrors the behavior of Zeebe and only reports an error if the called process ID is the same as the parent process ID. However, it also reports an error if the call activity is part of a potential loop regardless of the process it calls. This process deploys without errors:

Reported through Slack: https://camunda.slack.com/archives/C0693F1NFK5/p1707223390238339

Related to camunda/zeebe#13056

The rule should detect the following modeling patterns

• Validate that start forms are only supported in Camunda 8.3

As a result this example diagram should yield a human readable error:

A form on a is only supported by Camunda 8.3 or newer

How does the rule improve the BPMN diagram?

Ensure users can discover if start forms are supported.

Rule Details

• Name: start-form
• Default notification level: error

What alternatives did you consider?

None.