In der Anwendung werden die Komponenten in verschiedene Berechtigungs-Domains eingeordnet. In der Rollen-Rechte Konfiguration werden dann für eine Berechtigungsdomain nur diese Komponenten angezeigt.

Komponenten und Kommandos haben ihr eigenes Berechtigungsobjekt. Hier kann dann ein Berechtigungsobjekt konfiguriert werden, das nichts mit der Berechtigugs-Struktur zu tun hat, so dass inkonsistenzen konfiguriert werden können.

Verbesserung

• Es gibt keine Berechtigungsstrukturen mehr. Damit ist es nicht mehr nötig Rollen zu duplizieren (z.B. navigation oder selection) welche logisch gleich sind aber auf allen Berechtigungsstrukturen definiert werden.
• Der SecurityObjectProvider muss angeben, welche Typen das Security objekt haben können. Dann kann aus den Vererbungsregeln ausgerechnet werden, welche Rollen auf Objekten dieses Typs existieren können. So können die Optionen angeboten werden die theoretisch relevant sind.

Code-Migration

• Rollenregeln der Form {{{

<inheritance-rule

base="structureRoot@MyModule"
...

/> }}} ersetzen durch {{{ <inheritance-rule

...

>

<script-step expr="MyModule#ROOT"/>

</inheritance-rule> }}}

• Steps in Rollenregeln {{{

<step attribute="myAttr" meta-element="MyModule:MyClass" ... /> }}} ersetzen durch {{{ <step attribute="MyModule:MyClass#myAttr" ... /> }}}

• Zuweisungen von Rollen an Singletons für Gruppen müssen durch normale Rollenregeln ersetzt werden. In : {{{

<config service-class="com.top_logic.util.model.ModelService"> <instance><settings>

<module name="MyModule">
<singletons>
<singleton type="Root">
<role-assignments>
<role-assignment role="MyModule.role" group="MyGroup"/>
....

}}} das Tag <role-assignments> inkl. Inhalt entfernen. Statt dessen ein Rollen-Regel einführen: {{{ <singleton-rule

target="MyModule#ROOT"
role="MyModule.role"

>

<group-with-name name="MyGroup"/>

</singleton-rule> }}}

• Es sind Rollen "Navigation" und "Selektion" in der Basis vorhanden. Diese können statt der selbst definierten Rollen benutzt werden.
• Rollen werden nicht mehr an einem Modul definiert sondern in einer zentralen Registry. Model-Dateien und Konfigurations-Dateien müssen angepasst werden und die Rollendefinition verschoben werden.

Beispiel in myModule.model.xml: {{{ <module name="myModule">

<annotations>
....
<roles> <-- Tag entfernen
<role name="myModule.role1"/>
</roles>
</annotations>

</module> }}} Beispiel in Anwendungskonfiguration: {{{ <config service-class="com.top_logic.util.model.ModelService"> <instance>

<settings>
<module name="myModule">
<roles> <-- Tag entfernen
<role name="myModule.role1"/>
</roles>
....
</module>
</settings>

</instance> </config> }}} Stattdessen: {{{ <config service-class="com.top_logic.base.services.InitialRolesManager">

<instance>
<roles>
<role name="myModule.role1"/>
</roles>
</instance>

</config> }}} Info: Das Modul als Prefix zu nutzen ist nicht mehr nötig. Hier wird es nur mit Prefix hingeschrieben, da dies der Identifier ist und ansonstent die Rollen nicht mit den existierenden identifiziert werden können.

• Wird der SecurityObjectProvider "model" benutzt, sollte er, soweit möglich konkreisiert werden welchen Typ das Model haben kann. Hierzu suchen nach securityObject="model". Wenn das Modell in der konkreten Sicht z.B. entweder den Typ myModule:type1 oder myModule:type2 haben kann, sollte die Stelle ersetzt werden durch securityObject="model(myModule:type1,myModule:type2)"
• Das default-Verhalten ob eine button-bar (z.B. in Dialogen) angezeigt wird hat sich geändert und muss geprüft werden
• Das Verhalten ob ein layout als security-master betrachtet wird (z.B. wenn es im Dialog nur genau ein Layout gibt) hat sich geändert und muss überprüft werden. Besser eine Komponente explizit als security-master auszeichnen.
• Rollenprofile müssen aktualisiert werden.
• Security-Domain aus Layout-Dateien entfernen; Rollenregeln benötigen eine ID. Hierfür das Maven Target {{{

mvn exec:java@migrate-ticket29221 }}} ausführen. Layouts in der Datenbank werden automatisch aktualisiert.