enhancement
major
minor
major
minor
major
#29562
security.xml grants for a SecurityScopeService scope are lost on the start that introduces the scope: AccessConfigurationSetupService imports before the scope exists and stores the file hash anyway
Affects 8.0.0-SNAPSHOT (2026-09-11), tl-core (AccessConfigurationSetupService, AccessImporter) with tl-layout-view (SecurityScopeService).
Reproduction
An application declares a view-layer scope
{{{#!xml <config service-class="com.top_logic.layout.view.security.SecurityScopeService">
<instance><scopes><scope id="accounting">…</scope></scopes></instance>
</config> }}}
and grants it to a role in WEB-INF/conf/security.xml:
{{{#!xml <profile name="expenses.accountant">
<view name="accounting"><commandGroup name="Read"/></view>
</profile> }}}
On the start that introduces both, the log shows
Unknown view 'accounting', ignoring
(AccessImporter.java:45-48) and the role does not reach the scope. The import ran before SecurityScopeService had materialized the scope's PersBoundComp: the @ServiceDependencies of AccessConfigurationSetupService (AccessConfigurationSetupService.java:52-57) do not name SecurityScopeService. The file hash is stored regardless (:124-127), so the grant is not retried on the next start unless the file changes; the observed "the second start applied it" only happened while the file was still being edited.
Impact
A delivered application whose scope grants are in security.xml starts on a fresh database with no role reaching its scopes, and nothing repairs that later. The Permissions tab shows the scope row without a tick and nothing explains why.
Lösung
AccessConfigurationSetupService lives in tl-core and cannot declare a Java dependency on SecurityScopeService (tl-layout-view) without inverting the module layering. The service ordering is therefore declared where the scope service lives: tl-layout-view.conf.config.xml configures AccessConfigurationSetupService with a configured service dependency (<dependencies><dependency key="…SecurityScopeService$Module" value="true"/></dependencies>, the mechanism of ManagedClass.ServiceConfiguration#getDependencies()). Every application including the view layer thus imports security.xml only after all view-layer scopes have been materialized, so a grant to a scope is applied on the very start that introduces the scope.
The test TestSecurityScopeStartupOrder in tl-layout-view asserts that SecurityScopeService is among the transitive dependencies of AccessConfigurationSetupService under the application configuration. The React demo application tl-demo-react declares the role demo.react.Administrator and grants it the administration scope in its security.xml; on a fresh database the Permissions matrix of the administration area shows the grant on the first start.
The import result is not changed: an import naming an unknown role, view or command group is still recorded as applied and is not retried on later starts.