minor
#29089
Extend the TL Script functions log() and info() to include selectable message levels (INFO, WARN, ERROR)
#29306
TL Script: dateFormat() should accept an explicit timezone to format Calendar values losslessly
defect
major
#29383
A dead SOCKET_APPENDER (Chainsaw, localhost:4445) in the default logging configuration can cause logging to stall and operations to abort under heavy load
minor
#29380
Context-sensitive auto-numbering fails if the context and the numbered object are created within a single transaction
#29393
URL routing in the React view layer is broken: ForwardingReactContext does not delegate getRouteManager()
defect
major
#29394
Editable tables in the React UI: Generalized row-set bindings for tabular editing in forms
The React UI does not yet have a standard editable table—only the composition table (CompositionTableControl, rendered by `<composition-table>` inside a `<form>`) supports tabular editing. The legacy UI provided the GridComponent for this purpose (specifically, the selected row is editable while the component is in edit mode).
Instead of porting GridComponent, tabular editing has been generalized on top of the existing form editing framework (FormControl: edit session, lock, save/cancel, dirty tracking, FormValidationModel):
- An editable table is always a FormParticipant inside a <form>. A “standalone grid” is simply a form with a table as its only content.
- The cell-editing mechanics (one TLObjectOverlay per edited row, one AttributeFieldModel per row/column rendered through FieldControlService) are extracted from CompositionTableControl into a reusable controller.
- The row-set semantics are abstracted into a row-set binding that defines: what the row objects are, how a new row is created (and which types are available), what removing a row means at commit time, and what is written back upon persistence. Implementations:
- Composition: derived entirely from the composition reference (current composition table behavior): create concrete subtypes of the target type; remove deletes the orphan; persist writes the composition list to the form overlay.
- Reference (non-composition): rows are the reference value; adding may link an existing object and/or create a new one; removing only unlinks; persist updates the reference on the overlay.
- Query: Rows come from a TL-Script expression; add/remove semantics cannot be derived and must be configured (create-types, remove = delete or disabled); without such configuration, the table allows only pure cell editing of the query result.
- The edit policy (all rows editable vs. exactly the selected row—the grid behavior) is an independent configuration axis of the table.
- Unlike the legacy grid, there is no auto-apply upon selection change: edits are buffered on row overlays and committed in a single transaction upon save; validation blocks saving, not navigation.
- Row removal is buffered in the edit session and executed (unlink/delete) only during persistence.