A process decision can branch on a to-one relation of its trigger entity - #7679
Merged
delchev merged 2 commits intoOct 5, 2026
Conversation
The field loader inserted before a gateway published the trigger entity's own FIELDS only, so `if: "SendMethod == 1"` - branching on a nomenclature the row carries as a foreign key, which is how "e-mail it or print it" is modelled - got no loader at all. The identifier resolved only when a task form happened to post it as a variable; a completion through the Inbox API carries none, and Flowable then failed the expression on the unknown property and the instance stopped at the gateway. The foreign key is a number on the row like any other column, so all three halves are the ones the field path already walks: - `ProcessFieldLoadSupport.ownNames` looks for to-one relation names too, so the loader publishes the FK; - `BpmnIntentGenerator.ownFieldPascalCase` rewrites those names in the gateway's condition, to exactly what the loader publishes; - `StatusSymbolResolver` resolves a seeded NAME on the right-hand side against the nomenclature THAT relation points at - never the record's own status, which is a different nomenclature carrying a different id for the same word. Fixes eclipse-dirigible#7648 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
CodeQL flags the shared comparison regex as a polynomial ReDoS now that an authored decision condition reaches it: on a long run of identifier characters the engine restarts at every position and rescans the identifier, which is quadratic. Both identifier runs become possessive. A shorter run would end inside an identifier, where the trailing word boundary cannot hold, so backtracking into them could never produce a match - it only ever cost the scan. The language each pattern accepts is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7648
The field loader inserted before a gateway published the trigger entity's own fields only. So
if: "SendMethod == 1"— branching on a nomenclature the row carries as a foreign key, which is how "e-mail it or print it" is modelled — got no loader at all. The identifier resolved only when a task form happened to post it as a variable; a completion through the Inbox API carries none, Flowable failed the expression on the unknown property, and the instance stopped at the gateway.The foreign key is a number on the row like any other column, so the field path needed nothing new — only to look. All three halves:
ProcessFieldLoadSupport.ownNamescollects the entity's to-one relation names alongside its field names, so the delegate publishes the FK under the same PascalCase name a field gets.BpmnIntentGenerator.ownFieldPascalCasenow rewrites relation names in the condition too.StatusSymbolResolverrewrites<Relation> ==|!= <NAME>in a decision'sif:against the nomenclature that relation points at, not the record's own status — a decision may branch on any to-one, and the record's status is a different nomenclature carrying a different id for the same word. An ordering comparison against a name is refused, as it is at every other status site.Covered by the new
ProcessDecisionRelationTest: the name resolves against the relation's own nomenclature, the loader carries the foreign key before the gateway, and the emitted BPMN reads it under the name the loader publishes. There was no field-loader test before this one. The engine-intent suite is green: 1482 tests.