Major
Detail
Major
Detail
#26382
Error messages "Duplicate tag name..." when starting an application in the IDE from a TL-Studio
#26405
TTypeRewriter logs warning "Unable to resolve items by external reference" also unnecessarily
#26431
Changed superclass relationship leads to changed attribute list in the form editor only after a restart
#26484
In-app template for grid and tables: Function "Verifier for use as list item" does not get component model
#26536
When rendering HTML from TLScript expressions, configured renderers are not taken into account
#26797
Transaction with user input: invisible properties of the form model cannot be assigned values (initialized)
#26885
Constraints on declarative forms with arguments from a container reference lead to errors for new elements
#26921
ClassCastException when evaluating security rules that refer to (non-structuredElement) singletons of a module.
#26922
With generated subject classes, a default provider of an attribute in a non-structure class does not get a create context
#26988
In-app documentation generator does not extract documentation for overwritten config properties
#27027
Declarative forms: SelectField disappears after upload if option list depends on mandatory property
#27042
MaintenanceJspBase should write to the log first, then to the client, instead of the other way around.
Enhancement
Currently there is an explicit tl:MigrationProcessor that updates the schema stored in the database for the tl:KnowledgeBase. However, this operation breaks both an automatic schema migration and subsequent migration operations if they still refer to the original base line for the schema (e.g. the tl:DeleteTableProcessor).
Code migration
In migration scripts
#!xml <migration> <processors> <store-type-configuration/> </processors> </migration>
By
#!xml <migration schema-update="true"> <processors> </processors> </migration>
should be replaced. The schema update then happens at the end after all SQL and replay operations.
Test
Refactoring, no additional testing.