Currently, access rights administration in TopLogic is view-based: the PersBoundComp configuration defines which roles can execute which command groups in which views (CompoundSecurityLayout). While role assignments on model instances are already model-based, the final permission mapping (command group → roles) is tied to the layout structure.

For non-UI access paths (AI assistants, REST APIs, batch jobs, TL-Script), there is no natural view context to evaluate. This makes it impossible to directly answer questions such as “which users can read/update/create which model elements.”

This ticket tracks the design and implementation of a model-based access rights definition that:

• Defines access rules (operation → roles) on model elements (types, attributes, modules) rather than views
• Provides a ModelAccessRights API for programmatic access checks
• Allows views to derive their permissions from model-level rules
• Maintains backward compatibility with the existing view-based configuration

The specification document model-based-access-rights.md describes the current state and the proposed system in detail.

Migration

Model-based access rights are enabled by default in every application: the new SecurityConfigurationService is started by the framework, and all model access via TL-Script (and the Java API built on top of it) is checked against its configuration. The configuration is deny-by-default: a type without a grant for a command group is not accessible to any role-based user (administrators and code running in a system context bypass the checks).

An application that is updated without further action therefore continues to work for administrators, but regular users no longer see model data in TL-Script-based views, and TL-Script-based modifications fail. Every application must provide a <security-config> for its model.

1. Configure the access rights of the application model

Add a service configuration for com.top_logic.model.security.SecurityConfigurationService (e.g., as a separate *.config.xml file registered in the application’s metaConf.txt):

{{{#!xml <config service-class="com.top_logic.model.security.SecurityConfigurationService">

<instance>
<security-config>
<-- Baseline for all types of a module. -->
<module name="myapp">
<grant operation="Read" roles="Viewer, Editor, Manager" inherit="true"/>
<grant operation="Write" roles="Editor, Manager" inherit="true"/>
<grant operation="Create" roles="Editor, Manager" inherit="true"/>
<grant operation="Delete" roles="Manager" inherit="true"/>
</module>

<-- Refinement for a single type, e.g., a custom command group. -->
<class name="myapp:Order">
<grant operation="Approve" roles="Manager, Approver"/>
</class>

<-- Attribute-level restriction: narrows the type-level grant. -->
<part name="myapp:Customer#salary">
<grant operation="Read" roles="Manager"/>
<grant operation="Write" roles="Manager"/>
</part>

<-- A grant without roles denies the operation to everyone. -->
<part name="myapp:Contract#secret">
<grant operation="Read"/>
</part>

<-- Views without a domain type: use a module singleton as the security object. -->
<singleton name="myapp:AdminPanel">
<grant operation="Read" roles="Admin"/>
<grant operation="Write" roles="Admin"/>
</singleton>
</security-config>
</instance>

</config> }}}

Rules:

• An operation is a BoundCommandGroup: the built-in groups Read, Write, Create, Delete, plus any custom command group defined by the application.
• Type, module, and inherited grants are additive (union of the roles). Attribute grants (<part>) impose a restriction: the user must have the type-level right and one of the roles specified in the attribute grant. Singleton grants are standalone.
• inherit="true" propagates a grant to subtypes (for a module grant: also to subtypes defined in other modules).
• The referenced roles must exist in the database (e.g., declared via InitialRolesManager), and the roles are still assigned per instance as before (hasRole records, role rules, security parent chain). A role name that cannot be resolved is reported as a configuration error at startup.
• The starting point for the rewrite is the existing role profile of the views (PersBoundComp): the roles that were configured there for a command group become the roles of the corresponding grant on the displayed type. PersBoundComp itself remains unchanged and still governs the classic layout security.

A complete example is the configuration of the demo application in com.top_logic.demo/src/main/webapp/WEB-INF/conf/com.top_logic.model.security.SecurityConfigurationService.config.xml; the full concept is documented in specs/model-based-access-rights.md.

2. Where the new checks apply

• Reading an attribute in TL-Script ($obj.get(...)) returns an empty value if the user is not authorized to read that attribute on the object.
• Modifying (set, add, remove), creating (new), and deleting (delete) operations result in a TopLogicException if the corresponding right is missing.
• TL-Script-based model builders filter their results based on read access: ListModelByExpression, ModelProviderByExpression, TreeModelByExpression, SelectionUpdaterByExpression, TableContentProvider, ForeignObjectsTemplateProvider, and the script console.
• The `copy() ` method and the BPE process instantiation check the `CREATE` right.
• Not checked: computed (derived) attributes—they are evaluated using the definer’s rights—constraints, internal framework scripts, code in a system context, and administrators.
• `all() ` and `kbQuery()` deliberately return unfiltered results; the caller performs the filtering (in TL-Script using `filterSecurity()`, in Java using `SearchExpression.filterSecurity(...)`).
• A script executed without a logged-in user has no rights at all. Background jobs (tasks, batch processing) must run in a system context (ThreadContext.inSystemContext(...)) or use an executor with security disabled (see section 7).

3. Security parents: `getSecurityParent()` has been replaced

AbstractBoundWrapper.getSecurityParent() is now final and throws an UnsupportedOperationException. Applications that override the single-valued security parent must be adapted:

• Either override ` BoundObject.getSecurityParents() ` (returning a collection—the security hierarchy is now a DAG),
• or—preferred—configure the parent declaratively in the AccessManager:

{{{#!xml <config service-class="com.top_logic.tool.boundsec.manager.AccessManager">

<instance>
<security-parents>
<rule id="ProjectForMilestone"
inherit="true"
meta-element="myapp:Milestone"
>
<step attribute="myapp:Milestone#project"/>
</rule>
<rule id="SecRootForProject"
inherit="true"
meta-element="myapp:Project"
>
<singleton module="SecurityStructure"/>
</rule>
</security-parents>
</instance>

</config> }}}

Behavior change: the global security root is now used only as a fallback. As soon as security parents are configured for a type, the root is no longer added automatically. A type that requires the root in its parent chain must explicitly specify it using the new <singleton> path element (as in the example above). Otherwise, roles granted to the security root are no longer inherited by those objects.

4. Rule IDs

Role rules and security parent rules require an ID. Existing configurations are covered by the migration in #29221 (AddRoleRuleId); rules added manually need their own ID.

5. New framework configuration for accounts

• A new role, `PersonalProfile`, is declared (InitialRolesManager) along with a role rule that grants it to every user on their own account, plus read/write permissions for `tl.accounts:Person` and the corresponding contact configuration in `com.top_logic.contact`. This is what allows a user to view and edit their own account and contact information. Applications that already define a role with that name must rename theirs.
• Writing to tl.accounts:Person#admin is denied for everyone (grant without roles), i.e., the flag can no longer be set via model access (TL-Script, REST); it can only be changed through account administration.

6. Custom Java Code

• A QueryExecutor applies security by default. Internal queries that must access all objects regardless of the current user must explicitly call QueryExecutor.disableSecurity().
• Custom TL-Script functions implemented in Java that read or write the model should extend ` GenericMethodWithSecurity ` or ` SearchExpressionWithSecurity ` and evaluate `usesSecurity() ` (checking with `ModelAccessRights.getInstance()`), so that they can be disabled along with the surrounding expression. Plain GenericMethod implementations continue to compile, but they bypass model security.
• Programmatic access checks are available through the ModelAccessRights service (isAllowed, isReadAllowed, isAllowedCreate, getAllowedRoles, getAccessibleTypes); the corresponding TL-Script functions are canRead, canWrite, canDelete, canCreate, canReadAttribute, canWriteAttribute, canExecute, and filterSecurity.

7. Removed legacy module system and other Java API changes

The rework removed the legacy, properties-based service module family from com.top_logic.basic.module: RuntimeModule, ConfiguredRuntimeModule, MultiRuntimeModule, RuntimeModuleProxy, ServiceManager, DefaultServiceManager, and the constructors ManagedClass(Properties) / ManagedClass(IterableConfiguration). An application service that still uses them will no longer compile and must be converted to typed configuration:

{{{#!java @ServiceDependencies({ OtherService.Module.class }) // replaces getDependencies() public class MyService extends ConfiguredManagedClass<MyService.Config> {

public interface Config extends ConfiguredManagedClass.Config<MyService> {
@Name("some-option") String getSomeOption(); // one typed getter per former property
}
@CalledByReflection
public MyService(InstantiationContext context, Config config) { super(context, config); }
public static final class Module extends TypedRuntimeModule<MyService> {
public static final Module INSTANCE = new Module();
@Override public Class<MyService> getImplementation() { return MyService.class; }
}

} }}}

The former properties <section> become a <config service-class="..."><instance class="..." some-option="..."/></config> entry; a configurable implementation class (ConfiguredRuntimeModule class property, RuntimeModuleProxy) is the class attribute of <instance>.

Additional changes made by this ticket:

• The no-argument / Properties constructors of DataManager, FileSystemCache, FlexDataManagerFactory, EncryptedFlexDataManagerFactory, InitialDataSetupService, and CommandApprovalService are replaced by (InstantiationContext, Config) constructors; subclasses must implement them.
• BoundChecker#getRolesForCommandGroup(...) must return a non-null collection (Collections.emptySet() instead of null); the default allow(...) implementation no longer tolerates null.
• The ModelBasedSearch configuration property `disable-optimizations ` has been removed (the optimizer is always enabled); delete it from an application’s ModelBasedSearch service configuration, otherwise the configuration will fail with an “unknown property” error.
• RoleComputation(StorageAccessManager) has been renamed to RoleComputation(Person, StorageAccessManager); ElementAccessManager now includes the hooks getSecurityParents(BoundObject) and canHaveRole(TLClass, BoundedRole) for application access managers.
• AbstractCssClassUpdate.writeCssClassContent(...) is public abstract (a protected override no longer compiles).