1.4.1. Änderungen

Umstellung auf TypeScript 4.1

Es wird empfohlen das Projekte auch auf 4.1 umgestellt werden, da die TypeScript Versionen <=3.5 nicht mit TypeScript Versionen >=3.7 kompatibel sind und somit keine .d.ts-Dateien von Projekten mit TypeScript Version 4.1 (R3.0) in Projekten mit TypeScript Version <=3.5 verwendet werden können. Beispielsweise kann das entsprechende Nuget “Microsoft.TypeScript.MSBuild” in der gewünschten Version installiert werden.

Falls das Umstellen der TypeScript Version im Projekt nicht möglich ist, kann das Projekt weiterhin die alte TypeScript Version verwenden, es muss jedoch die tsconfig.json im Projekt angepasst werden. Hierzu muss der compilerOptions-Parameter um den Wert ‘“skipLibCheck”: true,’ erweitert werden, das sieht dann folgendermaßen aus:

`"compilerOptions": {`
`...`
`   "skipLibCheck": true,`
`...`
`},`

Mit diesem Parameter sollten die .d.ts-Dateien beim kompilieren nicht überprüft werden und es sollte zu keinen Build oder IntelliSense Fehlern kommen.

Migration TS 3.1 => TS 4.1

Bei der Umstellung auf die TypeScript Version 4.1 in Projekten kann es zu Migrationsaufwand kommen, da window bei Keys vom Typ any nicht mehr any-Values zurückgibt, sondern Values vom Typ Window.

Grundsätzlich ist es zu empfehlen das Verwenden von any zu vermeiden und den konkreten Typ zu ermitteln, es ist jedoch auch möglich weiterhin mit any zu arbeiten. Hier gibt es zwei Möglichkeiten:

1. Den Key für die window Klammer-Notation zu string casten.
   var myAnyVar: any = "any string";
window[myAnyVar as string].MyFunction();
2. Den Value der durch den Key gefunden wird von Window zu any casten.
   var myAnyVar: any = "any string";
(window[myAnyVar] as any).MyFunction();

Entfernung RelatedData

Unter RelatedData wird ein altes Konzept verstanden, um auf Quelldatensätze zuzugreifen. Es war möglich auf die direkten Vorgänger und auf den Kontakt, die nähste Firma und die oberste Firma zuzugreifen. Dieses Konzept wurde durch die Einführung der Hierachischen Relationen in 0.6 abgelöst. Mit dieser Version wurden nun die letzten verbliebenen Teile entfernt. Falls in Formeln diese Strukturen genutzt wurden, müssen diese Formeln auf “BAGetPrimarySource” umgestellt werden. Siehe dazu die manuelle Migration im technischen Handbuch. Programmatisch muss die folgende Zeile aus der Erstellung eigener Relationen entfernt werden.

relationConfiguration.Rules.Add(...);

Api.Type.GetConfiguration -> Api.Config.GetConfigurationClassOfType

Die Methode ist umgezogen. Falls sie verwendet wird, muss jetzt die Neue genutzt werden.

Signatur von Api.ORM.GetRelationDataModels geändert

Die generische Typisierung von GetRelationDataModels<T>(Session session, IEnumerable<Guid> oids) entfällt. Die Aufrufe sind entsprechend anzupassen, die Spitzen Klammern können entfallen. Der Rückgabewert ist jetzt IEnumerable<RelationData>` statt `IQueryable<RelationData>.

Umbenennung von RelationTools.GetFirstSourceOfType und RelationTools.GetTopSourceOfType

Die Methoden zu Hierarchieabfragen wurden so umgestellt, das der Typ nun optional ist. Die neuen Namen sind: GetHierarchyPrimarySourceNearest und GetHierarchyPrimarySourceTop. Methoden zum ermitteln der Oid anstatt der Datensätze wurden ergänzt (GetHierarchyPrimarySourceTopOid und GetHierarchyPrimarySourceNearestOid).

Name von LogException geändert

LogException heißt jetzt TranslatableException und residiert nun im Namespace BA.Core.Exception . Eventuelle Verwendungen dieser Exception sind entsprechend anzupassen.

Dateianhänge

Beim Update auf BusinessApp 3.x wird es notwendig, Dateianhänge von Datensätzen über ein konkretes Feld der Datentabelle anzuhängen und auszulesen.
Die Migration erstellt ein solches Standardfeld (“DefaultAttachments”) und konfiguriert es bei allen Verwendeten Dateianhangsmasken- und einigen Navigationssteuerelementen ein.

Es ist notwendig, das eigene Programmierungen nun auf dieses Standardfeld verweisen. Eine Beschreibung der neuen API finden Sie hier.

Api.ORM.GetNewORM(Guid type, Session s = null) -> Rückgabe nun OrmBABase

Diese Methode konnte vorher technisch auch nichts anderes zurückgeben. In der Regel ist keine Code Migrationen notwendig. Eventuell muss die Variable der Datentyp OrmBABase erhalten oder ein überflüssiger Casts kann entfernt werden.

Absicherung eigener Controller

Falls man eigene Controller implementiert hat und diese über [Authorize] abgesichert sind, muss nun [BAAuthorize] verwendet werden.

ClientActionSendEmail wurde entfernt

Durch die Migration werden in den Konfigurationen alle ClientActionSendEmail durch ClientActionSaveAndSendEmail ersetzt.

Sollte es in Projekten eigene Aktionen, die von ClientActionSendEmail ableiten, geben, dann müssen diese jetzt ClientActionSaveAndSendEmail ableiten.

Entfernung Relation Notification

Diese ungenutzte Relation war nur zwischen Contact und Notification möglich und wurde durch BA nicht genutzt. Falls sie in Projekten genutzt wurde, wird sie durch die Migration auf die Parent Relation umgestellt. Eventuelle programmatische Verwendung der Relation, muss ebenfalls umgestellt werden.

EnumRelationType.Notification