Hi ABP team,
We're building a multi-tenant healthcare product (outpatient queue management) on ABP Commercial 10.6.0 / .NET 10, modern multi-layer template, modular with the React UI, using the Low-Code System module for tenant-configurable data capture (e.g. pre-appointment questionnaires). Our deployment is database-per-tenant with separated host/tenant schemas — each tenant has its own database built from its own migration set.
What we've observed with the Low-Code module in this topology:
The designer model is a single global document: LowCodeModels has no TenantId, and when a tenant admin edits the model in the Admin Console designer, the mutations are persisted to the host database's model document (verified via LowCodeModelMutationHistories). Entities created by a tenant admin therefore appear in every tenant's menu. However, the physical table for a tenant-created entity is created by IDynamicTableCreator under the current tenant's connection, i.e. only in the creating tenant's database. The result is an entity that is defined platform-wide but whose table exists in exactly one tenant database — other tenants (and the host) see the entity but cannot use it. The dynamic permission definitions (Dynamic__<Entity>__*) are persisted to the host-side dynamic permission store only, so tenant users receive 403s on dynamic pages in separate-database tenants. Deleting an entity in the designer removes it from the model document but leaves the physical table in place (we understand this is deliberate data protection — a supported cleanup path would still be welcome).
Our questions:
Is tenant-scoped modelling on the module's roadmap? Specifically the semantics we need: host-authored entities shared with all tenants; tenant-authored entities private to the authoring tenant. The layered model architecture (DynamicModelLayerBase, ModelJsonComposer, RuntimeJsonDynamicModelLayer, DynamicEntititesModelCacheKeyFactory) looks purpose-built for a tenant overlay layer, so we'd rather wait for an official implementation than build one. If it's planned, is there a rough timeline? If it's not planned: what is the supported extension path? Is implementing a custom DynamicModelLayerBase-derived tenant layer plus a replaced IDynamicTableCreator (fanning host-published tables out to tenant databases) the intended seam, or are there internal assumptions (designer app service, concurrency stamp, mutation history, save points, EF model cache) that make this unsupported today? In the meantime, is the observed behaviour in (1)+(2) — tenant-admin edits landing in the global model while the table lands tenant-side — intended, or should we log it as a defect? For now we're revoking AbpLowCodeDesigner.* from tenant roles as a safety measure. Is there a recommended way to scope visibility of host-authored entities per tenant (e.g. via the dynamic permissions or features) that you'd consider supported?
1 Answer(s)
-
0
Hi,
Currently, the Low-Code System module does not support database-per-tenant deployments. Low-Code modelling itself is global rather than tenant-scoped. With a single database, tenant data isolation is provided by the underlying ABP multi-tenancy infrastructure, but this does not make the Low-Code model tenant-specific.
We do not currently have near-term plans to add tenant-scoped or layered modelling for separate tenant databases.
Regarding dynamic permissions, the current code generates permission definitions from the global Low-Code model. Admin-role permission grants are seeded using the current tenant context; however, the complete database-per-tenant topology is unsupported, so we cannot guarantee consistent model, schema, and permission behavior in this setup.
The layer and table-creator classes you mentioned are internal implementation details, not supported extension points. They may change between versions, so replacing or deriving from them would be fragile and would need to be maintained by your application.
There is also currently no supported permission- or feature-based mechanism for making individual Low-Code entities visible only to selected tenants. Since tenant-side Designer changes can modify the global model while schema operations affect the current tenant database, revoking
AbpLowCodeDesigner.*permissions from tenant roles is the appropriate safety measure.Therefore, the observed behavior should be treated as a consequence of an unsupported deployment topology rather than a supported tenant-scoped modelling workflow.
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)
