Wenn ein Account gelöscht wird und danach ein neuer Account angelegt wird, der den alten Kontakt wiederverwendet (siehe #28461), hat der neue Benutzer keine Berechtigungen. Es ist ein Full Security Rebuild nötig, damit der Benutzer seine Rechte wieder bekommt.

**Beispiel:**

• Ein Kontakt ist in einem Attribut "responsible" eingetragen.
• Es gibt eine Regel, die Personen in diesem Attribut eine Rolle zuordnen.
• Wird der Account dieses Kontakts gelöscht, werden alle Rollen aus dem SecurityStorage entfernt.
• Wird der Account neu angelegt und mit diesem Kontakt verknüpft, so wird die Security für diesen Kontakt nicht erneut inkrementell ausgerechnet (ElementSecurityUpdateManager).

Code-Migration

Rollenregeln des AccessManager (z.B. InitialRoleRule.xml) müssen umgestellt werden. Die Security funktioniert nur noch über das Modell, d.h. eine Regel benötigt zwangsläufigerweise ein "attribute" und ggfs ein "meta-element".

• Suchen und ersetzen von <step association=: Anstatt generell über die Assoziationstabelle zu navigieren muss das MetaAttribute herausgefunden werden dessen Werte in dieser Tabelle speichert und über dieses navigiert werden. Z.B. wird {{{

<step association="hasStructureChild" inverse="false" /> }}} zu {{{ <step attribute="children" inverse="false" /> }}}

• Suchen und ersetzen von <rule meta-object=: Anstatt den Tabellentyp anzugeben muss nun der TLModel type angegeben werden. Z.B. wird {{{

<rule meta-object="StoredQuery" ... }}} zu {{{ <rule meta-element="tl.search:StoredQuery" ... }}}

Daten-Migration

Die Migrationen Ticket_28710_Removed_legacy_types, Ticket_28710_Update_application_types und Ticket_28710_RoleAssignment_TLSearch (Modul tl-element) laufen beim ersten Start automatisch. Dabei ist zu beachten:

• Direkt zugewiesene globale Rollen gehen verloren. Die Tabelle hasGlobalRole wird ersatzlos gelöscht, ihre Daten werden nicht übertragen. Betroffen sind nur Anwendungen, die Rollen per Person#addGlobalRole(...) programmatisch vergeben haben (die Engine hatte dafür keine Oberfläche). Solche Zuweisungen sind vor dem Update als Gruppenmitgliedschaft plus Rollenregel abzubilden.
• Eigene Legacy-Tabellentypen muss die Anwendung selbst löschen. Die Module tl.legacy.tabletypes und tl.tables existieren nicht mehr; die Engine-Migration löscht nur die Typen der Engine (tl.legacy.tabletypes:PersonTable, tl.tables:PersonTableInterface, ...). Enthält die Datenbank der Anwendung noch eigene Typen dieser Module (aus dem Update von TL 6 nach TL 7 oder aus TableInterface-basierten Modellen), löscht die Anwendung sie in einer eigenen Migration (Vorlage: com.top_logic.demo/src/main/webapp/WEB-INF/kbase/migration/tl-demo/Ticket_28710_Removed_legacy_types.migration.xml) und typisiert Attribute um, die auf solche Typen zeigen (change-part-type ... target="tl.accounts:Person"). Konfigurationsverweise wie IndexedObjectNaming <type name="tl.legacy.tabletypes:..."> oder defaultFor="tl.legacy.tabletypes:..." sind zu entfernen.
• hasRole ist keine KnowledgeAssociation mehr, sondern ein MOKnowledgeObject vom Modelltyp tl.accounts:RoleAssignment (Referenzen source, dest, owner); definesRole und hasGlobalRole entfallen. Eigene *Meta.xml, die diese Tabellen referenzieren, sind anzupassen.

Code-Migration (Java)

• BoundedRole.HAS_ROLE_ASSOCIATION und DEFINES_ROLE_ASSOCIATION entfallen. Rollenzuweisungen werden über BoundedRole.assignRole(context, person|group, role) geschrieben und über getLocalAndGlobalRoles(context, person) sowie die Abfragen roleAssignmentsForContext(...), roleAssignmentsForRole(...) (liefern einen zu schließenden CloseableIterator) gelesen. Code, der getOutgoingAssociations(HAS_ROLE_ASSOCIATION) navigiert, muss umgestellt werden. Person#getGlobalRoles(), addGlobalRole(...) und removeGlobalRole(...) entfallen.
• LegacyFlexWrapper und StoredFlexWrapper entfallen: Wrapper-Klassen, die davon erben (wie StoredQuery und StoredReport in der Engine), erben von com.top_logic.element.meta.kbbased.AttributedWrapper; MapBasedPersistancySupport.getObjects(KnowledgeItem) und setObjects(Collection, KnowledgeItem) ersetzen die FlexData-Varianten.
• Die Erweiterungspunkte ExternalRoleProvider (<role-provider>) und SecurityStorageCommitObserver (<commit-observer>) am ElementAccessManager sowie FallbackAccessManager entfallen ersatzlos; programmatische Rollenvergabe ist als konfigurierte Rollenregel auszudrücken.
• AccessManager#handleSecurityUpdate(KnowledgeBase, Map, Map, Map, CommitHandler) heißt jetzt handleSecurityUpdate(TLObjectChangeSet, CommitHandler); ebenso LogHandler#logSecurityUpdate(TLObjectChangeSet, Map, Set). Eine Überschreibung mit der alten Signatur wird stillschweigend nicht mehr aufgerufen, wenn ihr @Override fehlt.
• RoleRule ist abstrakt (Implementierungen DefaultRoleRule, SingletonRule), PathElement ist ein Interface (Implementierung PathNavigation); RoleRule#matches(...) nimmt ein TLObject; ElementAccessManager#getRules() liefert Map<TLClass, Collection<RoleProvider>>.