Major
Nice to have
Detail
#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
Bugfix
Major
#25210
Modell-Referenzen in Konfigurationen müssen über Namen realisiert sein, falsche Abhängigkeiten in TestComponentConfiguration und Layout-Build-Tooling
DynamicComponentService: Layouts may refer to other typed layout definitions.
Abhängigkeiten zum ModelService müssen entfernt werden. Es darf nicht sein, dass man für das Build-Tooling (Layout-Overlay-Processing) die Anwendung mit ihrem Modell starten muss. Parameter der typisierten Konfiguration dürfen keine Referenzen auf Modell-Elemente enthalten. Insbesondere gilt das auch für Formular-Konfigurationen.
Test
- Formular mit formTable in-app konfigurieren.
- Layout in die IDE exportieren.
- TestComponentConfiguration aufrufen.
Das Problem ist die Auflösung des Arguments typeSpec, in dem der Zieltyp für das Formular gegeben ist.
Code-Migration
Sofern schon in-app Formulare existieren:
- In *.bpml, *.bpmn, *.xml suchen nach <formTable, <foreign-objects, und com.top_logic.layout.formeditor.parts.ForeignAttributeTemplateProvider
- Im gefundenen Tag das Attribut typeSpec durch type ersetzen.
- Diese Migration ist nur für Workspace-Konfigurtionen gedacht, nicht für Formulare in einem bestehenden Datenbestand. Formulare in der Datenbank werden automatisch migriert.
- Alternativ kann die Workspace-Migration auch automatisch über einen Shell-Befehl ausgeführt werden: find */webapp/WEB-INF/layouts -name \*.xml -print0 | xargs -0 -n 1 -I{} xsltproc -o "{}" com.top_logic/webapp/WEB-INF/kbase/migration/tl/Ticket_25210_Model_references_in_form_definitions.migration.xsl "{}" mit anschließender Normalisierung der Layouts.