major
nice-to-have
minor
#25217
Layout-Export führt zu invaliden Komponenten-Referenzen bei Referenzierung einer bestehenden Komponente
#25327
Modell-Editor: Falsche Kompositionsmarker, wenn Container-Typ in Diagramm von Content-Typ gezogen wird
defect
minor
#25759
Inkonsistente Prüf-Expressions in Command-Executability und Delete-Constraints
The executability signature for commands expects a boolean=true as the return value for executability.
The delete constraint on classes, on the other hand, expects "null" as the return value for executability.
That is, executability for delete commands: x -> if(<test>, true, #"object.delete.notAllowed")
The same delete constraint on the type: if(<test>, null, #"object.delete.notAllowed")
Here, it would be worth considering whether to align the signatures.
The variant with “null” has the advantage that the rule could be written as: if(!<test>, #"object.delete.notAllowed") ... because null is the implicit value for the else branch.
The variant with `true ` has the advantage that you could write the expression `<test> || #"object.delete.notAllowed"`... perhaps you want to treat both ` null ` and `true` as "ok"...
The variant with `true/false` has the advantage of being explicit. In my opinion, this makes it easier for users, since they have to explicitly consider what the situation is.
And it’s also closer to natural language. Execute? Yes/No.
Implementation
The two return types, null and true, are interpreted as executable.
This means the expression
x -> if(<test>, true, #"object.delete.notAllowed")
is “equivalent” to
x -> if(<test>, null, #"object.delete.notAllowed")
Test
TestDeleteConstraintWithBooleanReturnType.script.xml