In the application, components are assigned to different authorization domains. In the role-permission configuration, only these components are then displayed for a given authorization domain.

Components and commands have their own authorization object. Here, you can configure an authorization object that has nothing to do with the authorization structure, allowing for the configuration of inconsistencies.

Improvement

• There are no longer any authorization structures. This eliminates the need to duplicate roles (e.g., navigation or selection) that are logically identical but are defined across all authorization structures.
• The SecurityObjectProvider must specify which types the security object can have. The inheritance rules can then be used to determine which roles can exist on objects of this type. This allows the system to offer only those options that are theoretically relevant.

Code Migration

• Role rules of the form {{{

<inheritance-rule

base="structureRoot@MyModule"
...

/> }}} should be replaced with {{{ <inheritance-rule

...

>

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

</inheritance-rule> }}}

• Steps in Role Rules {{{

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

• Assignments of roles to singletons for groups must be replaced with standard role rules. 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"/>
....

}}} Remove the <role-assignments> tag, including its contents. Instead, introduce a role rule: {{{ <singleton-rule

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

>

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

</singleton-rule> }}}

• The "Navigation" and "Selection" roles are available in the base system. These can be used instead of the custom roles.
• Roles are no longer defined within a module but in a central registry. Model files and configuration files must be updated, and the role definitions must be moved.

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

<annotations>
....
<roles> <-- Remove tag
<role name="myModule.role1"/>
</roles>
</annotations>

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

<settings>
<module name="myModule">
<roles> <-- Remove tag
<role name="myModule.role1"/>
</roles>
....
</module>
</settings>

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

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

</config> }}} Note: It is no longer necessary to use the module as a prefix. It is only written here with a prefix because this serves as the identifier; otherwise, the roles cannot be identified among the existing ones.

• If the "model" SecurityObjectProvider is used, the possible types of the model should be specified as much as possible. To do this, search for securityObject="model". If, in the specific view, the model can have either the type myModule:type1 or myModule:type2, for example, the entry should be replaced with securityObject="model(myModule:type1,myModule:type2)"
• The default behavior regarding whether a button bar (e.g., in dialogs) is displayed has changed and must be checked
• The behavior regarding whether a layout is considered a security master (e.g., if there is exactly one layout in the dialog) has changed and must be verified. It is better to explicitly mark a component as a security master.
• Role profiles must be updated.
• Remove the security domain from layout files; role rules require an ID. To do this, run the Maven target {{{

mvn exec:java@migrate-ticket29221 }}} . Layouts in the database are updated automatically.